httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Rules of order for committers (Re: -current submitting policys)
Date Tue, 05 Mar 1996 21:08:41 GMT
These are some comment by Paul Traina over in FreeBSD land about commit
policy which although not directly applicable lay the basic ground rules
we should adopt here. There's some discussion about forming a policy document
there so I'll track the discussion and hopefully end up with a similar
document here.

----------------------------------------------------------------------------

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





Mime
View raw message