Re: Please discuss: what "git push" should do when you do not say what to push?

[Andrew Sayers <andrew-git@pileofstuff.org>]

On 19/03/12 22:59, Junio C Hamano wrote:
> Andrew Sayers <andrew-git@pileofstuff.org> writes:
> 
>> On 19/03/12 21:43, Junio C Hamano wrote:
>>>
>>> The same response applies. These administrators are taking responsibility
>>> for their users by making them out of our reach.
>>
>> I'm not sure I follow.  It sounds like you're saying we should avoid
>> helping anyone that doesn't stick to our upgrade schedule,...
> 
> I am not saying "should avoid".  I am saying it is not much use.
> 
> All we can do is to inform, educate and help those who are taking
> responsibility, be it LTS distro or these administrators, to help their
> users.  I've already outlined what LTS distros could do with backporting
> and reverting in the previous message.
> 
> We can make sure that the "default flip" and "stop warn" patches can be
> easily cherry-picked by them, even though we cannot force them to do so.

So we've identified the following groups:

1. People who can't be harmed by this change (e.g. new users and people
that would only ever use the new default behaviour)

2. People who are harmed by this change, and get information from this
list via some direct or indirect means (e.g. kernel devs or people using
a well-behaved distro)

3. People who are harmed by this change, are impervious to information
from this list, but update at sensible intervals and pay attention to
warning messages (e.g. corporate environments with frequent upgrade cycles)

4. People who are harmed by this change, are impervious to information
from this list, update at long intervals and pay attention to warning
messages (e.g. corporate environments with infrequent upgrade cycles)

5. People who are harmed by this change, upgrade their system
occasionally, but don't want to hear about behaviour changing from what
it has always been (Slackware users ;)

I guess we can agree that group 1 is already well cared for by recent
publicity, and group 5 is beyond our ability to handle.

Easy-to-cherry-pick patches are a good solution for group 2 - how about
also making a second "default flip" patch available earlier, for people
that want to go ahead of the main repo?  For example, Debian might want
to put this patch in before a feature freeze hits so that their build of
git behaves the same as everyone else once they've finished the
extensive QA process for the distro.

Warning messages as you've described them are a good solution for group
3.  I think we disagree about the size of this group, but I've only got
anecdotal evidence so what do I know.

People in group 4 aren't served well by any solution that involves some
day removing the warning altogether, because there will always be
someone that upgrades the day after we remove the warning and says "why
wasn't I informed?".

I assume the reason for removing the warning altogether is that some day
the signal:noise ratio will just get too bad.  Improving the S:N ratio
strikes me as useful even ignoring group 4, but anything that increases
the amount of time we can warn means that more of them will be informed.

This might have been implicit all along, but one easy way to improve the
S:N ratio would be to have the warning message tell people to use `git
config --global`.  Then people only ever need to see the message once
each, no matter how many repos they create.

We could also try to measure the S:N ratio by having a period where the
message says "... please e-mail git@vger.kernel.org if you found this
message useful, otherwise we'll assume nobody cares and delete it".
Then when somebody comes along and asks why they weren't informed, we at
least have a good answer.

Finally, as a modification to my previous suggestion, we could `git
config push.default <whatever>` when new repos are created and no
global/system push.default is found, *instead* of removing the warning
altogether at the end of the process. This would mean that everyone in
group 3 is informed, as are the vast majority of group 4.  The only
people that can then be harmed are those that do an exceptionally good
job of disguising themselves as new users (e.g. scripts that regularly
create throw-away repositories without ever looking at old ones).

	- Andrew