Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 11:06:34PM +0000, Russell King wrote:
 > On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
 > > In other words, we'd have an increasing level of instability with an odd 
 > > release number, depending on how long-term the instability is.
 > > 
 > >  - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
 > >    patches leading up to it (timeframe: a week or two)
 > > 
 > > with the odd numbers going like:
 > > 
 > >  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
 > >    to it (timeframe: a month or two).
 > >  - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
 > >    several releases (timeframe: a year or two)
 > >  - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
 > >    the kernel to be a microkernel using a special message-passing version 
 > >    of Visual Basic. (timeframe: "we expect that he will be released from 
 > >    the mental institution in a decade or two").
 > 
 > This sounds good, until you realise that some of us have been sitting
 > on about 30 patches for at least the last month, because we where
 > following your guidelines about the -rc's.  Things like adding support
 > for new ARM machines and other devices, dynamic tick support for ARM,
 > etc.
 > 
 > If I'm going to have to sit on this stuff for another month, it'll bit
 > rot rather badly, and I might as well throw away all these patches now
 > and ask people not to send stuff other than pure bug fixes.

The fact that this new approach serialises the stable/devel lineation
whereas traditionally it was parallel (2.x.y/2.x+1.y) is going to be
a real pain for a lot of maintainers.

In short, instead of a single 'merge with linus tree', I'm now going to
need a 'merge with linus' and 'merge with linus next time' tree for every
tree I maintain.. It's not impossible to maintain, but its extra burden.
Burden which a lot of folks may consider not worth it.

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/