* David S. Miller 2005-03-02 20:05
> On Wed, 02 Mar 2005 21:32:23 -0500
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > I also note that part of the problem that motivates the even/odd thing
> > is a tacit acknowledgement that people only _really_ test the official
> > releases.
> >
> > Which IMHO backs up my opinion that we simply need more frequent releases.
>
> This more frequent release idea will basically mimmick what the
> even/odd idea will do, except that even/odd will have specific
> engineering goals. Development vs. pure bug fixing.
Agreed, more frequent releases, even/odd, and 2.6.x.y all get down to
the same idea being making it easier for the end-user to test it and
thus achieving releases with less regressions.
I don't see any difference between 2.6.x.y and even/odd regarding
the process just after a stable release. The 2.6.x.y clearly has
the advantage that all those small nasty bugfixes such as missing
exports, typos and all the other one-liners can be brought to the end
user more easly in the middle of a development cycle. The even/odd
idea cleary has the advantage of a clear statement regarding what will
be the final release candidate. So let's combine both ideas and
get the advantages of both.
I think it is completely unimportant how to call it, be it .odd,
.even-test, .even-final-rc, 2.6.x.0 or whathever. The most important
part is to communicate this to the end-user. A well formed release
diagram on kernel.org would do just fine.
Basically it gets down to this:
+ > start of development cycle
| |<--+
| v |
| rcX -+
| |
| v
| final rc
| | (Only fixes here)
| v
+----- stable release -----> fixes branch---+
^ |
+-------------------+
It's already like this right now except that the final rc isn't
marked as such and a branch for stable release fixes (including
only the very imporant fixes) is missing. The situation for the
maintainers wouldn't change a bit.
Applied to combined even/odd and 2.6.x.y it would be:
2.6.12 -> 2.6.13-rcX -> 2.6.13 -> 2.6.14 -> 2.6.15-rcX
|
v
2.6.14.y
My personal preference would be to suffix the final odd release with
-test just to more clearly mark it but that's a very minor cosmetic thing.
I'm not sure wehther the test release thing will increase the number
of testers but it's sure worth a try. A real advantage would be that
everyone interested in a smooth migration to the next stable release
can give the test release a try and will see eventual regressions
fixed before the final stable release with a very low risk of new
regressions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
