Date: Sat, 31 Jul 1999 21:42:26 +0200 From: Poul-Henning Kamp <phk@freebsd.org> Subject: Sitting inside, looking out... Message-ID: <14964.933450146.1@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
------- =_aaaaaaaaaa
Content-Type: message/rfc822
Content-Description: Original Message
Subject: Sitting inside, looking out...
From: Poul-Henning Kamp <phk@freebsd.org>
Date: Sat, 31 Jul 1999 21:42:26 +0200
Message-ID: <14964.933450146@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
Bcc: Blind Distribution List: ;
MIME-Version: 1.0
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 core@freebsd.org 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 <gussie@alaska.net>, 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...
Poul-Henning
PS: See you all at the FreeBSD-con in October! http://www.freebsdcon.org/
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
------- =_aaaaaaaaaa--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14964.933450146.1>