Andrew Sayers [off-list ref] writes:
On 19/03/12 21:43, Junio C Hamano wrote:
quoted
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.
On 19/03/12 22:59, Junio C Hamano wrote:
Andrew Sayers [off-list ref] writes:
quoted
On 19/03/12 21:43, Junio C Hamano wrote:
quoted
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
Andrew Sayers [off-list ref] writes:
I assume the reason for removing the warning altogether is that some day
the signal:noise ratio will just get too bad.
The reasoning is a lot simpler than that.
If the end game is not remove the warning, then we would be switching to a
new default that is "give loud warning until the user configures her own
default, but push upstream/current anyway" mode. We do not want such a
stupid mode as the default---we want the default to be either upstream or
current at the end, when nobody remembers what the ancient default was.
The "warn loud but do it anyway" is a very good interim step during the
migration, but is never a good default. If we are going to stop there,
"give loud warning until the user chooses and configures the default, and
push nothing" mode would be a LOT safer and saner default, as it would
really force people to configure the default. Obviously we do not want to
go there, so...
On 20/03/12 23:09, Junio C Hamano wrote:
Andrew Sayers [off-list ref] writes:
quoted
I assume the reason for removing the warning altogether is that some day
the signal:noise ratio will just get too bad.
The reasoning is a lot simpler than that.
If the end game is not remove the warning, then we would be switching to a
new default that is "give loud warning until the user configures her own
default, but push upstream/current anyway" mode. We do not want such a
stupid mode as the default---we want the default to be either upstream or
current at the end, when nobody remembers what the ancient default was.
The "warn loud but do it anyway" is a very good interim step during the
migration, but is never a good default. If we are going to stop there,
"give loud warning until the user chooses and configures the default, and
push nothing" mode would be a LOT safer and saner default, as it would
really force people to configure the default. Obviously we do not want to
go there, so...
It sounds like we're disagreeing, but I can't tell what about. I agree
that "warn loud but do it anyway" is a bad default in the long term. I
propose implementing the behaviour you want by adding a push.default
setting to the .git/config file for all new repositories, so that users
with a longer-than-expected short term still get the warning. That
should warn 99% of the people who need it without bothering anyone that
doesn't. What am I missing?
- Andrew