Re: [PATCH v3] Add core.mode configuration

[John Szakmeister <john@szakmeister.net>]

On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
[snip]
> We cannot change the behavior of push.default = simple already, so at least
> that option is not in question.

True.

> Presumably you are worried about the other options that can't be enabled in any
> way.

Yes.

> But think about this; you are worried that if we add an *option* to enable this
> new behaviors, then we would be kind of forced to keep these behaviors. That
> seems to imply that you are proposing the current default; we wait until 2.0
> and not make it an *option*, but make it *default*.
>
> I think waiting until 2.0 to make it a default without evern having an option,
> and thus nobody actuallly testing this, is way worst than what I'm proposing;
> to add an option to start testing.

My concern is that people don't treat it for what it is--a way to
experiment with the new behaviors--and then they get upset if we
discover that some behavior was not well thought out and it disappears
"unexpectedly" when we correct the matter.  We have a balance to
strike: annoying users and getting some miles on the new behaviors.  I
see the technical end of this--your proposal to have a
'core.mode'--but where is the non-technical end of this argument?
What message are we proposing to send to the users?  What's our
promise to them surrounding core.mode and the new behaviors it offers?
 Perhaps we don't have much today that this affects, but what about
tomorrow?  Are we saying that behaviors enabled by core.mode=next are
concrete (they're going in as-is, and we won't alter their behavior
before 2.0)?

As I said, the only real drawback is that I see this as the latter,
because any other choice means users will get annoyed when something
changes out from under them.

>> So, at the end of the day, I'm just not sure it's worthwhile to have.
>
> This is exactly what happened on 1.6; nobody really tested the 'git foo'
> behavior, so we just switched from one version to the next. If you are not
> familiar with the outcome; it wasn't good.

You're right, I wasn't around for that.  And on the whole, I
absolutely agree: it's nice to get miles on these new
behaviors/features/etc.  I just worry that having an option like this
means we've committed to it, and I'm not sure that we want to give up
the ability to change them without having to go through some sort of
deprecation cycle.  Or worse, we have to wait until 3.0 and 2.0 hasn't
even come out yet.

I hope others chime in here.  And don't mistake me as dissenting; I'm
not.  And, I'm not assenting either.  I just want to know if you've
thought about what this means to users, and what we're prepared to
deal with.  Right now, I feel like half the argument around the option
is missing.

> So I say we shouldn't just provide warnings, but also have an option to allow
> users (probably a minority) to start testing this.

"probably a minority" -- I guess that's the part I disagree with.  I'm
not sure what a minority means here, but I don't think it'll be a
handful of people.  How big does that number get before we get
concerned about backlash from users if we decide to change course?
Or, is that simply not an issue?  Why or why not?  I have to be
honest, if the option was available, I'd have my developers turn it
on.  I'm sure a great deal of others would do so too.

Is there some other way we can solve this?  Having an experimental
branch with all the 2.0 features merged and those concerned can just
build that version?  I see the downside of that too: it's not as easy
for people to try, and there is nothing preventing folks from posting
binaries with the new behaviors enabled.  It leads me to feeling that
we're stuck in some regard.  But maybe I'm being overly pessimistic
here, and it's really all a non-issue.  As I said earlier, it'd be
nice if others chimed in here.

-John