Re: new dev model (was Re: Default cache_hot_time value back to 10ms)

[Matt Mackall]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/