[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFD: Kernel release numbering
On Wed, 2 Mar 2005, Lars Marowsky-Bree wrote:

> On 2005-03-02T14:21:38, Linus Torvalds <> wrote:
> > We'd still do the -rcX candidates as we go along in either case, so as a
> > user you wouldn't even _need_ to know, but the numbering would be a rough
> > guide to intentions. Ie I'd expect that distributions would always try to
> > base their stuff off a 2.6.<even> release.
> If the users wouldn't even have to know, why do it? Who will benefit
> from this, then?
> I think a better approach, and one which is already working out well in
> practice, is to put "more intrusive" features into -mm first, and only
> migrate them into 2.6.x when they have 'stabilized'.
> This could be improved: _All_ new features have to go through -mm first
> for a period (of whatever length) / one cycle. 2.6.x only directly picks
> up "obvious" bugfixes, and a select set of features which have ripened
> in -mm. 2.6.x-pre releases would then basically "only" clean up
> integration bugs.
> -mm would be the 'feature tree'. Of course, features which have matured
> in other eligible trees might also work; the key point is the two-stage
> approach and it doesn't matter whether the chaos stage has one or three
> trees, as long as it's not more than that.

Certainly -mm can be the feature tree, but i've noticed that not that many
people run -mm aside from developers. Meaning that a fair number of bugs
seep into Linus' tree before they get attended to. It would even be more
effective if we could get more -mm user coverage. A Linus based odd number
might be closer to that if we hope on people unwittingly running them.
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: 2005-03-22 14:10    [W:0.487 / U:5.856 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site