Re: lkml, bugme.osdl.org?

[davidsen@tmr.com (bill davidsen)]

In article <20021204124227.GB647@suse.de>,
Dave Jones  <davej@codemonkey.org.uk> wrote:

| indeed. this should be addressed by the time we get to stable releases.
| One possibility someone came up with at the summit was just a slightly
| different take on the existing pre/rc release model.
| The initial pre's remain as they are now, later pres are for strict
| bug-fixes and arch resyncs, then the release candidates roll out.
| It doesn't sound that impossible a plan, as long as whoever ends up
| doing it is strict enough not to include 'just one more feature'
| during the arch-merge pre's.

  This should fall out in the early rc versions I would think. Once new
features are stopped and only bugfixes are allowed, I'm not sure that
fixes to make an arch work are different from any other bugfix.
Otherwise you can get a "fix-lock" where a kernel get ported to most
archs, then a real bug is found and fixed which breaks some arch, then
we go round again.

  In practice, if new features are strictly kept out, the rc releases
should asymptotically approach stable.

  I'm not against having a "port-stable" stage, I just think it isn't
going to speed development. The maintainer would have to decide if a bug
fix could wait if it broke a port, but they do a lot of "is it a fix or
a feature" now, if you call a patch "fix missed detection of foo123
chip" it's a fix, and if you say "add detection of foo123" it becomes an
enhancement.

  Release maintainers have a really hard job, that's why we pay them the
big bucks;-)
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.