Re: RFD: Kernel release numbering

[Linus Torvalds]

On Fri, 4 Mar 2005, Linus Torvalds wrote:
> 
> In other words: I'm talking about scalability of development, not about 
> fixing every single serious bug. I think this one will catch the 
> embarrassing brown-paper-bag kinds of things, and maybe 90% of the "duh, 
> we had this race forever, but we never even realized", but it wouldn't 
> solve the ones where we had "damn, we did the locking wrong".

Btw, I also think that this means that the sucker-tree should never aim to 
be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the 
sucker tree would be _included_ in that release (and it may indeed be all 
of it - most of the time it probably would be), but we should not assume 
that "2.6.x.y" _has_ to be just the sucker tree.

We might want to release a "2.6.x.y" that contains a patch that is too big
or too intrusive (or otherwise controversial) to really be valid in the
sucker-tree.

And I'd want that to be very much explicit in the "charter" for the
sucker-tree. Exactly because the whole point (to me, at least) is to make 
it _easy_ to maintain. There should never be any discussion at all about 
patches: either they are universally loved, or they are not. And if the 
sucker-tree is seen as a 2.6.x.y release tree, then that will _inevitably_ 
mean that people will start discussing whether one patch or the other is 
supposed to go in.

My personal gut feeling is that 90% of the patches I _ever_ see are
"obvious". If we also cut them down to "must fix an oops/hang/roothole", I 
think we'll actually get quite far with a sucker tree. We'll never get all 
the way, but exactly because the tree wouldn't _try_ to get all the way, 
it would be a lot easier to maintain.

And let's face it, just getting 50% of the way and having somethign that 
catches the brown-paper-bag stuff so that nobody else every needs to worry 
about them is really worthwhile.

		Linus
-
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/