On Tue, Feb 14, 2012 at 10:36:32PM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > If you are running v1.7.8.1 now, even if v1.7.9 is out, it is less risky
> > to move to v1.7.8.2 than to move to v1.7.9.
> [...]
> 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.
That's a good point. Maint releases are not well tested before release.
However, I think there are two things that help balance that:
1. The commits that go onto them are "obviously" correct. I put
obviously in quotes, because of course we can make a mistake. But
just looking at the commits that end up in a typical maint release,
they're usually quite conservative.
So in deciding between v1.7.8.4 or v1.7.9, it is a question of
whether you are more likely to be screwed by a conservative commit
that has gotten less testing, or by one of the host of
non-conservative commits that have gotten more testing.
I don't think we have numbers on the historical balance (and going
forward, it would really depend on qualitative factors like "how
conservative" anyway).
2. The commits on maint are often tested in isolation. That is, they
are not generally cherry-picks, but were rather branched and
developed from a maint-worthy version, and then forward ported into
master (where forward porting for us is basically merging plus
adding any required tweaks). So in an ideal world, the developer
considers the fix looking at the maint code, and then the risky
forward-porting happens in master (where we have time to cook and
squash bugs).
On the other hand, just because the developer comes up with the fix
based on an old version doesn't mean that they don't make a
mistake. And with nobody running it, those mistakes may slip
through. Also, we do sometimes base bugfixes on the source of a
bug, which is ancient, and then merge up not only to master but
also to maint. The right fix at the source of the bug may be
different than what is needed at maint, which is different than
what is needed at master.
Hmm. I really wish we had some numbers, because it's very unclear to me
which factor dominates. My gut says that the maint releases are still
safer, even with the problems you listed. I recall multiple bugs in
feature releases that caused quick bugfix releases. I don't recall
offhand having to quickly issue a fix for a maintenance release.
> > Which implies to me that in an ideal world, there would be maint
> > releases for the current series (i.e., v1.7.9.x now) and the previous
> > one (v1.7.8.x now). Somewhere around v1.7.9.3 (or after 3 months, or
> > whatever), stop bothering with v1.7.8.x releases.
>
> Actually what I was thinking was to restructure the release schedule
> slightly so that
>
> * We do not merge to 'master' anything but bugfix patches to regressions
> introduced by 1.7.10 or to new features introduced by 1.7.10, for two
> weeks after it ships;
>
> * During that time, if an urgent fix is needed, 'maint' is directly
> patched to produce 1.7.9.X, and it is merged upward to 'next';
>
> * After finishing applying the early fixes to 1.7.10 to 'master', we tag
> the tip of 'master' as 1.7.10.1 and fork 'maint' from there;
>
> * 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.
I think that is not so far from what I proposed (except that my "3
months or whatever" is your "2 weeks and one version").
> Yes, that's the crucial observation to make. Cherry-picking or down
> merging fixes tested in a new context to older codebase that is not
> actively used by the person who is cherry-picking does not produce a
> stable end product. It only produces stale end product. It makes it
> slightly scarier to imagine that the cherry-pick is done by people who
> may not be as familiar with the codebase as us, but on the other hand,
> they might be using that old codebase for their day-to-day work, and may
> have better luck hitting issues that did not manifest themselves in the
> context of 'master' and 'next.
Good point. I thought of them as less-qualified, but in many ways they
are more so.
Hmph. You've certainly given me something to think about. I joined this
thread thinking you were a little bit crazy, but now I think you are
starting to convince me. :)
-Peff
--
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