FreeBSD mail list etiquette

[Pierre Beyssac]

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 at enst.fr