[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: new dev model (was Re: Default cache_hot_time value back to 10ms)
On Wed, Oct 06, 2004 at 03:48:01PM -0400, Jeff Garzik wrote:
> So my own suggestions for increasing 2.6.x stability are:
> 1) Create a release numbering system that is __clear to users__, not
> just developers. This is a human, not technical problem. Telling users
> "oh, -rc1 doesn't really mean Release Candidate, we start getting
> serious around -rc2 or so but some stuff slips in and..." is hardly clear.

The 2.4 system Marcelo used did this nicely.. A couple -preX to shove
in new stuff, and a couple -rcX to iron out the bugs. 2.6.x-rc[12]
seem to be similar in content to 2.4.x-pre - little expectaction that
they're actually candidates for release.

> 2) Really (underscore underscore) only accept bugfixes after the chosen
> line of demarcation. No API changes. No new stuff (new stuff may not
> break anything, but it's a distraction). Chill out on all the sparse
> notations. _Just_ _bug_ _fixes_. The fluff (comments/sparse/new
> features) just serves to make reviewing the changes more difficult, as
> it vastly increases the noise-to-signal ratio.

Also, please simply rename the last -rcX for the release as Marcelo
does with 2.4. Slipping in new stuff between the candidate and the
release invalidates the testing done on the candidate so someone can't
look at 2.6.9 and say "this looks solid from 2 weeks as a release
candidate, I can run with it today".

Mathematics is the supreme nostalgia of our time.
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:06    [W:0.057 / U:24.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site