On 19/03/12 22:59, Junio C Hamano wrote: > Andrew Sayers <andrew-git@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html