Date: Wed, 29 Oct 2003 15:00:54 +0100 From: Pierre Beyssac <beyssac@enst.fr> To: Terry Lambert <tlambert2@mindspring.com> Cc: Kip Macy <kmacy@fsmware.com> Subject: Re: FreeBSD mail list etiquette Message-ID: <20031029150054.A40485@bofh.enst.fr> In-Reply-To: <3F9AC703.4DBAA14C@mindspring.com>; from tlambert2@mindspring.com on Sat, Oct 25, 2003 at 11:54:59AM -0700 References: <200310230143.32244.wes@softweyr.com> <20031025175948.GF683@funkthat.com> <3F9AC703.4DBAA14C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 25, 2003 at 11:54:59AM -0700, Terry Lambert wrote: > Frankly, FreeBSD has too many cooks, and not enough bottle washers; > this is a euphimism for saying that all anyone with a commit bit > seems to want to do any more is write new code, and no one is > willing to take on the integration and maintenance tasks. In Linux, > this work is done by Linus, Alan Cox, and a couple of other people. > People get commit bits so that they can do integration, and so that > patches don't sit in bug databases for 6 years unintegrated. > > The problem with this imbalance, is that you seem to be unwilling > to hire bottle washers, and people willing to wash bottles when > there are no clean bottles left are never given any respect, and > certainly not the level of respect accorded to cooks. I believe that's mostly a problem with FreeBSD 5. I partly agree with your analysis, in that too much attention is given to new developments, and not quite enough to stability fixes. Where I differ is that I believe the problem doesn't lie with commit bits attribution, but rather with the inherent complexity of the FreeBSD 5.x kernel. The 5.x kernel is a hell of a lot more difficult to work on than the 4.x kernel. More than once I've been unable to debug stuff myself under 5.x, due to giant push, locking intricacies, KSE, mutexes... The result seems to be that just a few people master each part of the kernel. The others either work by trial-and-error, or don't dare to work at all except in limited, obvious cases or in their area of competence. Two simple things could probably help: - having minimal documentation for developers about how to develop and debug the 5.x kernel, explaining stuff like KSE, mutexes, ... -- this is easier said than done, and a job in itself. Just maintaining -- or advertising -- a set of pointers to relevant man pages and source code samples, explaining the spirit of this stuff, would be a good start. - extending regression tests, trying to add new relevant tests when bugs are fixed. It is also easier said than done, but it is easier to distribute among people. Following Mike Silbersack's suggestion I've been trying to do that for bugs I fix, which as noted above does not happen often these times. On a different note, the checkpoint code announcement which started all this thread seems an extremely interesting functionality to me, thank you Kip for posting this information. -- Pierre Beyssac pb@enst.fr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031029150054.A40485>