Junio C Hamano wrote: > But think again, with the intimate knowledge of how these bugfix topics > are merged down to older maintenance tracks. [...] > But nobody in the development community rebuilds 'maint' every time it is > updated and runs the result as his or her primary production version. Even > I do not do that (remember, I run 'next'). I only build and run full test > suite. Older maintenance tracks are worse. I do not think anybody runs > them before they are tagged and released. I can offer one data point. In the context of Debian sid, Gerrit and I do test each version in daily work before uploading it. I generally build from and test whatever track is going to be used for the next upload (usually plus a few extra features I am interested in for private use) a little while before the release, to be prepared. Anders sometimes uploads to the Ubuntu PPA which brings more testers. After the upload, users running "sid" test for about a week before even more users running "testing" get to take a look at it and test for the sake of later users who will run "stable". So little bugs get discovered, with time to fix them. Even with this, the extra time to migrate from 1.7.6 to 1.7.7, for example, was very helpful in the context of Debian sid. Like it or not, new features *do* come with minor regressions, and it helps the sanity of a package maintainer to not have to suffer people who did not request a bleeding-edge release complaining about regressions until there has been time to fix them. Of course, this has nothing to do with Debian stable, which is an orthogonal story. I'll discuss that below. [...] > * At that point, old 'maint' and 1.7.9.X track cease to receive updates, > as there is no point maintaining them. It only encourages distros to > stay behind, adding unnecesary maintenance burden to us. If you are thinking of distros like Debian stable, then that is just wishful thinking. Dropping support for old releases does not have any effect except to cause patches to be missed there. (See iceweasel and chromium-browser for examples where using the version in Debian stable is something I would usually not recommend.) This may seem weird, but keep in mind that people like you and me are not the target audience for the git package in Debian stable. We use git heavily. If I am on a machine running stable or RHEL, I will build a private copy of git in $HOME or ask the sysadmin to install a more recent git as the first thing I do. The reason that packages go into Debian stable and then just _don't change_ is that the target users are not using those packages heavily. If a new feature (e.g., "signatures from tags get incorporated into the merge commit from pulling them") causes a regression (e.g., "the script I used to run every week that pulls my favorite software package and builds it just stopped working"), then these people get zero benefit, for a sizable cost. Though that's a digression. The relevant detail to mention here is that there is real demand on downstreams to continue to maintain packages without adding new features. They will help to maintain old releases if you want. If we want to influence that maintainance, for example to ensure security bugs are fixed correctly and in the same way everywhere, a good way is to keep a maintenance branch. Hoping that clarifies a little. Jonathan -- 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