FreeBSD mail list etiquette

[Matthew Dillon]

    I think it needs to be recognized that *no* submission or suggestion,
    whether by core, a committer, or an outside member, will ever survive
    its original maintainership 'forever'.  This is true for everything that
    was ever put into the kernel throughout its entire history:  VFS, VM,
    BIO, KLD, ELF, Makefiles, the Scheduler, and it is true of all
    new contemporary work as well (Geom, Slab Allocator, Mutexes, Thread
    scheduler rules, Security work, etc..).

    For any outside submission, it is up to the inside project members to
    take up the ball and do the final step if they want the work in the
    project.  Heaping conformistic requirements on an outside originator
    will simply result in the work not ever getting into your tree.  It's
    really that simple.  After all, FreeBSD is not going to be the focus
    for any outside submission (KAME's history in the tree being a really
    good example of this).  Regardless of their intent, the lack of
    involvement by the general FreeBSD developer community has led to
    some severe issues over the years, yet it is equally obvious that
    there is great demand for the work.  The outsider is not going to be
    tracking FreeBSD development anywhere near as tightly as FreeBSD
    insiders do, which makes the idea of requiring a FreeBSD-specific
    patch set in the first place rather silly.

    So it simply becomes a matter of whether there is a developer within 
    the project who feels that a piece of work is interesting enough to do
    the last bit required to integrate, document, and bring it into your
    project in a fashion that can be maintained generally according to
    the rules of that project... and then move on.

    The work is certainly germane.  Really, any open-source work is germane,
    especially on the a list like freebsd-hackers :-).  The FreeBSD project
    is an open-source project, after all, even if some of its developers
    treat it as their own personal fiefdoms and people are afraid to cross
    maintainership boundaries because they get their heads bitten off every
    time they do.   The whole maintainership and stewardship concept has
    seriously stratified FreeBSD development, to the point where some very
    bad technical decisions have been made over the last few years (Hence
    DragonFly's existence).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>

:On Sat, Oct 25, 2003 at 12:41:35PM -0700, Marcel Moolenaar wrote:
:> 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.
:> 
:> The euphemism sucks, but the point is there. The problem here has
:> nothing to do with commit bits. People who do the dirty work and
:> do it in a way that demonstrates that they can do it unattended
:> are given commit bits. The problem is that after a certain amount
:> of dirty work someone either goes away or, if given a commit bit,
:> moves on to more interesting things to waste time on.
:> 
:> There is also a problem in that the dirty work, even if done in a
:> way that demonstrates that the person has skills, is not always
:> recognised as important. The recognition has to come from within
:> that part of the developer community that has commit bits, because
:> you need someone with a commit bit to actually commit the stuff. If
:> noone with a commit bit recorgnises the dirty work as important,
:> it's not going to be committed and the person who has done the dirty
:> work is not recognised as someone who is worthy of a commit bit
:> because none of his work has been committed.
:
:And to add to the complexity the non-committer providing patches
:has a much better chance of obtaining his/her own commit bit if the
:patches are committed to the repo.
:
:That is the (in?)famous track-record that has been discussed before
:that is one of the gating factors for a commit bit.
:
:Puzzling.. to say the least..
:
:Wilko