Date: Tue, 05 Mar 1996 11:02:54 -0800 From: Paul Traina <pst@shockwave.com> To: ejc@nasvr1.cb.att.com Cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, dob@nasvr1.cb.att.com, committers@FreeBSD.org Subject: Paul's rules of order for committers (Re: -current submitting policys) Message-ID: <199603051902.LAA16512@precipice.shockwave.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
In no way did I take your message as a personal criticism. This was an
example of someone following the intended procedure pretty well and blowing
it totally nevertheless, which will occasionally happen. That's why it's
-current.
Now, for the record, let me state what I think the policy needs to be, and
then throw it open for debate. I doubt there will be much. In one or two
cases, I may mention specific events, these are for illustrative purposes only
and in no way am I pointing fingers at people. (In fact, I'm doing this now
because of my rather spectacular double-screw-up...no one can accuse me of
taking the high road. :-) ).
(a) don't break tree builds
- try to do commits in an atomic fashion, minimize windows of
vulnerablility if you can't be perfect
(b) don't commit non-functional code
- it's not ok to commit stuff that doesn't work. if you're working
on something and want to let people know there is work-in-progress,
just send mail to committers or current or hackers as appropriate.
if you want people to test something, put it up separately for ftp
- it's ok to commit stuff that doesn't quite work that is NEW, as
long as it's not linked into the system -- this should only be
done for collaborative efforts that are complex enough that using
CVS as a go-between is a big win. (this is the exception rather than
the rule).
(c) code review code review code review
- in a perfect world, EVERY commit should have two pairs of eyes go
over it before it goes in... glasses don't count.
- the world isn't perfect, so use your best judgement. If you're
not familiar with the area you're touching, find one of the area
gurus and coordinate with them, or, worst case, send a broadcast
"please sanity check me" message to committers.
- the more complex, the more important the code review
- the code reviewer takes his or her job seriously, reviewing other
people's code for errors is actually more important than writing code,
don't do a half-assed job. At cisco, when someone introduces a bug
the code reviewer takes as much negative energy as the author.
(d) changes to fundamental semantics need to be announced BEFORE committing
- don't pull the rug out from under people
- don't change things just because you don't like it
- don't make us more incompatible with 4.3, tahoe, BSDI, and NetBSD
just because you don't "like" something
(e) funky changes to the heart of the OS should get backed out if they're
causing lots of grief
- e.g. if a change to the kernel is made and things start breaking for
a big number of people, back it out and test with the individuals.
As an example, we had a -current kernel that was useless for almost
a month because of bugs in an updated subsystem. This halts the
development effort for everyone else, or, worse, causes people to
do "blind" commits without adequate testing
From: ejc@nasvr1.cb.att.com
Subject: Re: -current submitting policys
Hello
My request for information on current development policies
was in know way a judgement on Paul's quality of development. If my
request was taken wrong, because of it's implicit connect to the previous
-current make world failure, I would like to apologies to Paul. Paul I'm
sorry if you took my post the wrong way, please continue your development
on FreeBSD it is appreciated.
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?
Eric J. Chet (ejc@nasvr1.cb.att.com || ec0@ganet.net)
Lucent Technologies, Bell Labs
Columbus, Ohio
> As ejc@nasvr1.cb.att.com wrote:
>
> > This brings up a few questions at least for me. Should the code be
> > buildable and installable on the developers machine with the latest
> > -current before submitting? Should a code diff be inspected by
> > another peer before submitting?
>
> We are all humans only. Paul did follow all of this, he's been asking
> in -current before, and he had his change peer-reviewed, as you can
> see in the log message:
>
> revision 1.3
> date: 1996/02/23 17:57:32; author: pst; state: Exp; lines: +2 -1
> If a .db file is 0 length, initialize it as if it did not exist.
> Reviewed by: wollman
>
> Nevertheless, once used on much more than two machines, the real
> problems with it started popping up. You can hardly blame Paul for
> this accident, even though the consequences were fatal for a number of
> people.
>
> --
> cheers, J"org
>
> joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RI
>>PE
> Never trust an operating system you don't have sources for. ;-)
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603051902.LAA16512>