Re: RFD: Kernel release numbering

[Dave Jones <davej@redhat.com>]

On Wed, Mar 02, 2005 at 05:20:49PM -0800, Andrew Morton wrote:
 > Dave Jones <davej@redhat.com> wrote:
 > >
 > > So what was broken with the 2.6.8.1 type of 'hotfix kernel' release ?
 > 
 > That's an alternative, of course.
 > 
 > But that _is_ a branch, and does need active forward- and (mainly)
 > backward-porting work.
 > 
 > There's nothing wrong with it per-se, but it becomes a "stabilised version
 > of the kernel.org tree" or even a "production version of the kernel.org
 > tree".  In other words it's somewhere on the line between the mainline
 > kernel.org tree and a distribution.  How far along that line should it
 > be positioned?

In an ideal world, we'd see a single 'y' release of 2.6.x.y, but if x+1 takes
too long to be released, bits of x+1 should also appear in x.y+1
The only question in my mind is 'how critical does a bug have to be to
justify a .y release.  Once a new 'x' release comes out, the previous x.y
would likely no longer get any further fixes (unless someone decides the
new 'x' sucked so bad).

Linus using bitkeeper should actually remove most of the pain from this
multiple branch thing though. If fixes alternatively get checked into x.y
and new development goes into x+1, x+1 could do a daily pull of x.y
Thus saving the having to check in fixes to two seperate branches.
(which really really sucks under some SCMs).

		Dave