We have repeatedly heard that -core's communication with the
developers leaves something to be desired, so I'll venture this
attempt at improving it.

This email is NOT a official statement from core, it is MY PERSONAL
attempt, as a core member, at improving communication between core
and the developers.

I will try to represent the consensus -core as faithfully as I can,
but make no mistake:  this is seen through my glasses.

1. Core decisions

A lot of you have been asking for -core direction and decisions on
various issues, and mostly you didn't get any such thing.  It seems
that is the way the core team as such wants things to be.  I think
the best way to express it is that the core team sees itself as a
supreme court, not as a governing board:  We only act when all
other avenues of closure have failed.  Think of it as "gigamanagement"
rather than "micromanagement".

In general the core team doesn't make more than a handful of
decisions a year (that is not counting appointing committers) and
there isn't resonance in -core for changing this level of activity.

So how are things decided in this project if not by -core ?

Well, working code speaks loud and clear, thats for sure, but
otherwise it happens exactly the way you see it: people discuss
things in the mailing lists and try to reach agreement.

But if you want to get a core decision on something, make sure that
you send an email to [EMAIL PROTECTED] with the question.  You cannot
expect any reaction from -core by posing the question in some random
maillist.  Make sure to include sufficient background and references
to the subject, at least half of the core members have not heard
of the discussion before.  And please use a distinctive subject
on your emails, "proposal for new committer" is a distinctively
bad subject line, much better would be "Samuel B. Morse for committer ?"

In the past -core has not been very good at even answering emails,
but I have been trying to improve that by assuming a self-styled
secretary function: as best I can I try to keep track of outstanding
items and make sure they don't fall through the cracks.  If you
don't get a response from -core, nag me with an email, and I will try
to make it happen.

2. Who are the committers anyway ?

All the noise about Matt Dillons commit bit have generated a lot
of questions about who gets to be committers, so here is a little
insight into the process of appointing a committer:

Generally we in core operate with three kinds of committers:

    Ports committers
        These are people who maintain one or more ports.

        If Asami-san wants to glue a bit on somebody, we will 
        generally let him.

    Limited scope committers
        These are people who maintain some specific bit of the tree,
        typically a subsystem they are (co-)authors of.  A good example
        is the HARP ATM stack, which Mike Spengler is taking care of
        (and many thanks for that Mike!)

        Since these people are taken on board with a explicitly 
        stated limited scope, we are more relaxed about them than
        we are about the last category.  People have been known
        to successfully sneak out from this category and into:

    Committers at large
        These are the people who persist in sending well documented
        PRs containing correct patches.  The only way we have
        devised so far for ridding ourselves of this kind of
        annoying behaviour is to say "Here! you're a committer,
        now close your own PRs!" :-)

For all these three categories some general rules apply, or rather
if they apply the answer is a resounding "no":

    Flaming people and generally presenting the attitude that people
    who don't agree with you should leave the planet on the first
    available rocket (or otherwise), is the most reliable way to
    not pass the muster.  It doesn't matter how good you are
    technically, if you can't work in a group, your not in this
    particular group.

    Being unresponsive to input is another good way to fall through.
    Some of the people are right 99.994% of the time, but nobody
    is right 100% of the time.  If people point out to you that
    something you did or said isn't right, listen to them, think
    about it more than once, they could be right.  [even Bruce has
    been caught on the wrong foot once, that's where I got the
    99.994% figure from :-) ]
    Wasting peoples time.  We're all here on borrowed time, most
    of us have jobs, families, cats, houses, you name it, things
    that also have legitimate claims to our time.  Needlessly
    wasting peoples time is not welcome, in particular when it is
    their spare time.

If you match any of these descriptions, and if you have proved that
you can code or document, and have some time to spare, you'll pass
the muster, no worries.  And don't despair: we generally appoint a
"mentor" for all new committers.  The mentor is responsible for
helping the new committer "learn the ropes", and generally help
them get cross the threshold without getting eaten by the lions.

And I hope it is all worth it for the committers, because you are
certainly the biggest asset we have in the project.  I'm sorry that
there isn't much but the title and the rather limited fame we can
offer you in return.

        NOTE: If somebody can find a sponsor for it, I would really
        like to offer an "official FreeBSD Committer sweat-shirt"
        to each and every single committer.  Luxury cars, free
        vacations and suitcases filled with cash would also do.

3. The GNATS database, who handles it ?

Simple: You do.

Even if you are not a committer, you can help out:  Find a PR,
try to reproduce the problem if you can, then try to fix it if
you can.  If the PR contains a patch, try it out.  And at the
end, send a follow up to the PR with your results.  A PR with a
complex patch has much better chances of getting committed if
the PR has a couple of follow-ups which say "works for me"
than if it just sits there.

4. mac68k as a new platform ?

We have been contacted by Grant Stockly <[EMAIL PROTECTED]>, who
informed us that he has a almost finished port of FreeBSD to the
mac68k platform.  [In general I would advice that people drop
the core team a note early in such an undertaking.  It would be
a pity if somebody else was doing the same thing and you couldn't
work together just because you didn't know about each other].

The core team is very keen for more platforms, but a certain level
of interest and support from users and developers is needed before
we will add a platform as an official part of FreeBSD, so now is
the time for those of you who have an interest in the mac68k or
68k support in general, to rally around Grant and work with him on
this.  Our postmaster will happily create a mailing list if you
want it.

That's all for now folks...


PS: See you all at the FreeBSD-con in October!  http://www.freebsdcon.org/

Poul-Henning Kamp             FreeBSD coreteam member
[EMAIL PROTECTED]               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!

Reply via email to