On 18/03/12 18:50, Junio C Hamano wrote: > Andrew Sayers <andrew-git@xxxxxxxxxxxxxxx> writes: > >> On 17/03/12 05:22, Junio C Hamano wrote: >>> If the conclusion of the discussion is that we will change the default, >>> the transition to the new default will go like this: >>> >>> 1. An announcement message to let the user communities know about the >>> future change will be distributed in a way similar to the previous >>> request-for-discussion message was distributed. >>> >>> 2. The first version of Git that is released after such an announcement >>> will start issuing a warning ... >>> >>> 3. We wait for a few release cycles. >>> >>> 4. The default changes. ... >>> The warning message will be reworded ... >>> being the 'matching' in the future", it will say "has changed to X". >>> >>> 5. We wait for a few release cycles. >>> >>> 6. The warning is removed. >>> >>> A typical release cycle lasts for 8-10 weeks. >> >> Unfortunately, "a few release cycles" strikes me as a rather hopeful >> description. For example, a user installing the new Ubuntu LTS release >> (due out next month) would feel completely justified in not upgrading >> until 2017, whereas the rest of us would get rather bored disabling the >> same old warning in every new repo we create for the next five years. > > There is nothing hopeful about it. > > The point of a release like LTS is to shield the users of the distribution > from what happens in upstream, so it is up to the distro to help users. We > do not have a way to help their users in a direct way, other than letting > the distro know about the change, and educate the distros how they help > their users. > > If I were a user of such a distro whose sole point is a long term support, > I would expect that a LTS that was originally released before point #2 > whose lifespan extends beyond point #6 to backport only the "warning" > changes to such a release between #2 and #6 timespan as a point update to > such a LTS release. Otherwise the distro is actively doing a disservice to > its users. Such a distro can also choose to revert the "warning removal" > change #6 in their binary when they release a new LTS. If they did not > backport "add warning" to their earlier LTS release, that is at least what > they can do to help their users. > > But again, that is not something we have direct control over, and it is > not very useful to discuss this on this list. Ubuntu LTS support forum > might be a better place, but in short, it is not a problem we can solve > (nor we should be solving), as long as we have a reasonable migration plan > and if the user is locked out of that migration plan---whoever is doing > the locking-out is taking responsibility for these users who are out of > our reach. > > -- > 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 > I take the point that distros have their own support infrastructure, so perhaps this would be a better example: Many administrators in corporate environments will install git from source, because they don't trust RPM/need some feature in the latest version/are just that way inclined. Having installed it, they tend to sit on that version for a few years until they have to upgrade the system/need some feature in the new latest version/are still just that way inclined. Their justification for not upgrading is often that new versions of software tend to change behaviour in subtle ways that break the scripts they've bodged together over the years. Trying to argue that one particular bit of software will only hurt you if you wait for the wrong amount of time tends to be a losing battle, because administrators hate special cases just as much as programmers. Having said all that, here's a slightly different argument for a slightly better solution: When a user upgrades to a mid- or post-change version of git, I think it's a good idea for them to be warned about the change of behaviour. But new users, and old users with new repositories, gain nothing from the little history lesson. This should be solved in git itself, because two users of the same binary might expect different behaviour. An automatic `git config push.default <whatever>` at repository creation time would silence the noise without disrupting the signal. As an added bonus, this approach might take some heat out of the argument when the umpteenth "is it time to remove the warning yet?" thread kicks off. - 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