Re: RFD: Kernel release numbering

[Jeff Garzik <jgarzik@pobox.com>]

Greg KH wrote:
> 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." 

We have all these problems precisely because _nobody_ is saying "I'm 
only going to accept bug fixes".  We _need_ some amount of release 
engineering.  Right now we basically have none.


> 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.

Easiest to answer with a concrete example:

Linux 2.6.11 is released.  Linus then does a
	bk clone linux-2.6 linux-2.6.11

Bug fixes that
(a) 2.6.11 users really should have, or
(b) Linus/Andrew feels are important, or
(c) a subsystem maintainer feels are important [and does the work to 
split out the fixes]

go into linux-2.6.11 repo, and then is pulled into linux-2.6 repo.

All other changes go into linux-2.6.

There's no need to over-think or over-work this.  The goal is to provide 
a stable 2.6.11 for users, until 2.6.12 is available.

My prediction is that several patches will flow into the linux-2.6.11 
repo a week or so after a release, and then the flow will die off to a 
trickle.  Subsystem maintainers that care can submit patches/BK-pulls 
for the stable release if they so desire.

Only important "oh shit, that should have been in 2.6.11" bug fixes need 
apply.  Bug fixes for reworks, API changes, etc. are -not- applicable to 
linux-2.6.11 repo.

Since BitKeeper can handle nicely a
	cd linux-2.6
	bk pull ../linux-2.6.11
there is no duplication of bug fixes.

	Jeff