From: Matt Mackall <mpm@selenic.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Andrew Morton <akpm@osdl.org>,
mingo@redhat.com, nickpiggin@yahoo.com.au,
kenneth.w.chen@intel.com, linux-kernel@vger.kernel.org,
judith@osdl.org
Subject: Re: new dev model (was Re: Default cache_hot_time value back to 10ms)
Date: Wed, 6 Oct 2004 19:02:07 -0500 [thread overview]
Message-ID: <20041007000207.GV5414@waste.org> (raw)
In-Reply-To: <41644BF1.7030904@pobox.com>
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.
next prev parent reply other threads:[~2004-10-07 0:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-06 0:42 Default cache_hot_time value back to 10ms Chen, Kenneth W
2004-10-06 0:47 ` Con Kolivas
2004-10-06 1:02 ` Nick Piggin
2004-10-06 0:58 ` Nick Piggin
2004-10-06 3:55 ` Andrew Morton
2004-10-06 4:30 ` Nick Piggin
2004-10-06 4:51 ` Andrew Morton
2004-10-06 5:00 ` Nick Piggin
2004-10-06 5:09 ` Andrew Morton
2004-10-06 5:21 ` Nick Piggin
2004-10-06 5:33 ` Andrew Morton
2004-10-06 5:46 ` Nick Piggin
2004-10-06 6:19 ` new dev model (was Re: Default cache_hot_time value back to 10ms) Jeff Garzik
2004-10-06 6:39 ` Andrew Morton
2004-10-06 8:56 ` Paolo Ciarrocchi
2004-10-06 9:44 ` bert hubert
2004-10-06 14:00 ` Andries Brouwer
2004-10-06 19:40 ` Jeff Garzik
2004-10-06 19:48 ` Jeff Garzik
2004-10-06 19:58 ` Jeff Garzik
2004-10-06 20:37 ` Geert Uytterhoeven
2004-10-07 1:08 ` Jeff Garzik
2004-10-07 0:02 ` Matt Mackall [this message]
2004-10-06 9:23 ` Ingo Molnar
2004-10-06 9:57 ` Paolo Ciarrocchi
2004-10-06 19:33 ` Jeff Garzik
2004-10-06 22:23 ` Martin J. Bligh
2004-10-06 5:52 ` Default cache_hot_time value back to 10ms Chen, Kenneth W
2004-10-06 19:27 ` Chen, Kenneth W
2004-10-06 19:39 ` Andrew Morton
2004-10-06 20:38 ` Chen, Kenneth W
2004-10-06 20:43 ` Andrew Morton
2004-10-06 23:14 ` Chen, Kenneth W
2004-10-07 2:26 ` Nick Piggin
2004-10-07 6:29 ` Ingo Molnar
2004-10-07 7:08 ` Jeff Garzik
2004-10-07 7:26 ` Ingo Molnar
2004-10-06 20:50 ` Ingo Molnar
2004-10-06 21:03 ` Chen, Kenneth W
2004-10-06 7:48 ` Ingo Molnar
2004-10-06 17:18 ` Chen, Kenneth W
2004-10-06 19:55 ` Ingo Molnar
2004-10-06 22:46 ` Peter Williams
2004-10-06 13:29 ` [patch] sched: auto-tuning task-migration Ingo Molnar
2004-10-06 13:44 ` Nick Piggin
2004-10-06 17:49 ` Chen, Kenneth W
2004-10-06 20:04 ` Ingo Molnar
2004-10-06 21:18 ` Chen, Kenneth W
2004-10-07 6:10 ` Ingo Molnar
2005-02-21 5:08 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041007000207.GV5414@waste.org \
--to=mpm@selenic.com \
--cc=akpm@osdl.org \
--cc=jgarzik@pobox.com \
--cc=judith@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.