Re: RFD: Kernel release numbering

Linus Torvalds
2005-03-04T18:26:43Z

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