From owner-freebsd-current Sat Jul 31 12:44:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id C9FA614C57; Sat, 31 Jul 1999 12:44:42 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id VAA14966; Sat, 31 Jul 1999 21:42:26 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) Date: Sat, 31 Jul 1999 21:42:26 +0200 Message-ID: <14964.933450146.1@critter.freebsd.dk> From: Poul-Henning Kamp Subject: Sitting inside, looking out... MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" Content-Description: Blind Carbon Copy Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------- =_aaaaaaaaaa Content-Type: message/rfc822 Content-Description: Original Message Subject: Sitting inside, looking out... From: Poul-Henning Kamp 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 , 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-current" in the body of the message