Messages in this thread | | | Date | Fri, 13 Jun 2003 13:29:31 +0200 | From | Stephan von Krawczynski <> | Subject | Re: Linux 2.4.21-rc8 |
| |
On Thu, 12 Jun 2003 09:59:56 +0100 John Bradford <john@grabjohn.com> wrote:
> > Saying it is a bad idea to release a kernel with known bugs > > is like saying it is a bad idea to buy a computer when the > > price will be going down soon. Would you care to delay > > 2.4.21 until next spring or would you rather get the fixes > > it contains today and have 2.4.22 with your pet fix on > > (hopefully) a scale of weeks? > > A lot of the known bugs have fixes which appear to be OK, but haven't > really had enough testing to go in to a -final tree. A lot of them > won't have been tested on SMP boxes for example.
One of the more important things in kernel development - according to my personal opinion - is the fact that there is _one_ main tree and you may well ignore others. The more you split up, the less testing there will be. There is only a certain amount of people that really use not-released kernels. If you produce more branches the total amount of tests done will not really increase but rather decrease (per branch) because of the split-up. Don't do that, please And another thing is: your proposal seems to increase load on the maintree maintainer. I don't think this is the right way to go. I would rather say the subsytem maintainers should be more involved. Which means: if a subsystem does not work as expected or the patches are a mess, then I'd say it's the maintree maintainers job to kick the a** of the subsystem maintainer to solve it, and not to solve the problem himself. Surely he can give hints and suggestions - who wouldn't - but the work should be done by the maintainer. I think this is the fundamental idea behind maintainership.
Regards, Stephan - 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/
| |