Date: Tue, 05 Mar 1996 12:40:51 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> 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 Message-ID: <4915.826058451@time.cdrom.com> In-Reply-To: Your message of "Tue, 05 Mar 1996 08:06:06 EST." <9603051306.AA06002@ginger.cb.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4915.826058451>