[lkml]   [2005]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFD: Kernel release numbering

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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean