lkml.org 
[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new dev model (was Re: Default cache_hot_time value back to 10ms)

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.

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.

With all the noise of comment fixes, new features, etc. during Release
Candidate, you kill the value of reviewing the -rc patch. Developers
and users have to either (a) boot and pray or (b) wade through tons of
non-bugfix changes in an attempt to review the changes.

I know it's an antiquated idea, _reading_ and reviewing a -rc patch, but
still...

Jeff



-
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: 2005-03-22 14:06    [W:0.974 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site