From owner-freebsd-current  Tue Mar  5 12:42:26 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA22503
          for current-outgoing; Tue, 5 Mar 1996 12:42:26 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA22485
          for <freebsd-current@FreeBSD.org>; Tue, 5 Mar 1996 12:42:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id MAA04917; Tue, 5 Mar 1996 12:40:51 -0800 (PST)
To: ejc@nasvr1.cb.att.com
cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de,
        dob@nasvr1.cb.att.com
Subject: Re: -current submitting policys 
In-reply-to: Your message of "Tue, 05 Mar 1996 08:06:06 EST."
             <9603051306.AA06002@ginger.cb.att.com> 
Date: Tue, 05 Mar 1996 12:40:51 -0800
Message-ID: <4915.826058451@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@FreeBSD.org
Precedence: bulk

> 	On the other had I did not receive a single message on formal
> development policies for FreeBSD.  I assume the policies for FreeBSD are
> then just personal development policies?

Well, no one has actually sat down and formulated a policy that one
could print out and stick on the wall, but there is nonetheless a sort
of collective policy that's enforced by the core team and understood
by most of the developers who've been around for awhile.  When I say
it's "enforced", I also simply mean that if a developer commits
something that offends enough people's sensibilities in some way,
enough negative response is generated that the problem self-corrects.

Once a developer has been around for awhile, and perhaps been on the
receiving end of such negative feedback once or twice, they get a
fairly clear picture of what's expected.

If I had to describe these expectations in actual words, I'd probably
make something like the following list:

1. Test your changes before committing them (this one really gets
   you slapped).

2. Obey existing the existing style conventions of code you modify - no
   gratutitous reformatting to fit your own personal style.  Code you
   write yourself is a different matter, and only rarely is it deemed
   necessary to comment on this (e.g. if your style involves the
   elimination of all whitespace, you'll probably get at least one
   comment saying "yuck!!" :-).

3. If you're planning on making an extensive change, or one that will
   change the calling syntax of some function or utility, you must propose
   it in the freebsd-current mailing list first and give people a chance
   to comment on the wisdom of such a change.

4. Respect existing domains.  If you know for a fact that Tom and Dick
   have been working away on the VM system, you should probably coordinate
   any plans of your own in this area with them.  If you're not sure
   of the state of existing development in some area, ask first.  No answer
   received in a reasonable time-frame can be taken as a "go ahead."

5. If you're not sure of the efficacy of your approach, have someone
   else agree to review it for you before committing it.  This request
   can be sent to -current if you've not already got a "FreeBSD buddy"
   picked out (just like Scuba diving :-).

6. If you're really having problems coordinating some change, talk
   to the core team - that's what they're there for.


And that's about it!

					Jordan