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. - 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/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:22 EST