lkml.org 
[lkml]   [2005]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2011 Jasper Spaans