Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 02:52:21AM -0500, Jeff Garzik wrote:
> 2.6.x.y has a very real engineering benefit:  it becomes a stable 
> release branch.  That will encourage even more users to test it, over 
> and above a simple release naming change.
> 
> Users have been clamoring for a stable release branch in any case, as 
> you see from comments about Alan's -ac and an LKML user's -as kernels.

Sure they've been asking for it, but I think they really don't know what
it entails.  Look at all of the "non-stable" type patches in the -ac and
as tree.  There's a lot of stuff in there.  It's a slippery slope down
when trying to say, "I'm only going to accept bug fixes." 

Bug fixes for what?  Kernel api changes that fix bugs?  That's pretty
big.  Some driver fixes, but not others?  Driver fixes that are in the
middle of bigger, subsystem reworks as a series of patches?  All of this
currently happens today in the main tree in a semi-cohesive manner.  To
try to split it out is a very difficult task.

So, while I like the _idea_ of the 2.6.x.y type releases, having those
releases contain anything but a handful of patches will quickly get
quite messy.

Not to mention the issue of the need for me as a maintainer to mark
"bugfix only" specific patches and pull them out and submit them
separately.  Due to api changes, and all sorts of other issues, that can
get to be a difficult job in itself.

Personally, I like the current, "test it all in -mm and then forward the
good bits to Linus" mode we are operating in.  My only suggestion would
to possibly speed up the release cycle a bit faster than every two
months, like we currently are on.  Once a month perhaps?  That was how
we were working at the beginning of 2.6, and it seemed like the backlog
was much smaller then.

thanks,

greg k-h
-
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/