From owner-freebsd-current  Wed Mar  6 17:52:49 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id RAA25921
          for current-outgoing; Wed, 6 Mar 1996 17:52:49 -0800 (PST)
Received: from gw3.att.com (gw4.att.com [204.179.186.34])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA25820
          Wed, 6 Mar 1996 17:52:26 -0800 (PST)
Received: from clipper.cb.att.com by ig4.att.att.com id AA05294; Wed, 6 Mar 96 18:47:28 EST
Received: by clipper.cb.att.com (4.1/EMS-1.1 SunOS)
	id AA20415; Wed, 6 Mar 96 16:42:00 EST
From: Daniel.M.Obrien@att.com
To: ejc@naserver1.cb.att.com, pst@shockwave.com
Cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de,
        committers@FreeBSD.org, terry@lambert.org, jkh@time.cdrom.com
Received: from cbsky.cb.att.com by clipper.cb.att.com (4.1/EMS-1.1 SunOS)
	id AA20391; Wed, 6 Mar 96 16:41:53 EST
Received: by cbsky.cb.att.com (5.x/EMS-1.1 client.cf 1/8/94 (SMI-4.1/SVR4))
	id AA10817; Wed, 6 Mar 1996 16:41:51 -0500
Date: Wed, 6 Mar 1996 16:41:51 -0500
Original-From: dob@clipper.cb.att.com
Message-Id: <9603062141.AA10817@cbsky.cb.att.com>
Original-To: ejc@nasvr1.cb.att.com, pst@shockwave.com
Subject: Re: Paul's rules of order for committers (Re: -current submitting policys)
Original-Cc: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de,
        committers@FreeBSD.org, terry@lambert.org, jkh@time.throck.com
X-Sun-Charset: US-ASCII
Sender: owner-current@FreeBSD.org
Precedence: bulk

> (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).

One observation I have made after 1) recently experiencing a ``broken 
-current'' (Sig 11's), and 2) watching submits really, really close (waiting 
for a fix), what disturbs me most are consecutive submissions saying ``Did 
this...''  and then ``Oops, shouldn't have done that...''  

I guess it is good that the ``fix'' is turned around quickly, but what bothers
me is that I'm left with the feeling that the source submission process 
(source tree) is being used as a place to park changes rather than parking 
them locally (on developer's system), and compiling & soaking them on the 
developer's system.  (Thus bending Paul's unwritten rules above.)  

If the ``Oops'' submission didn't happen in time, nothing prevents me and 
others from pulling the changes and installing them into our systems.  If the 
submitter found the ``Oops'' so quickly, why wasn't it found before the 
original submitting?  

My minds eye suggests the process being followed is 1) make change, 2) submit,
3) try it, 4) ``Oops'', 5) make new change, 6) submit, 7) try it....
This is based on my anecdotal observations of submits.

I don't mind being a guinea pig testing code on my ``unique'' system, but 
would rather not be the first one to try something new...  unless it's code I 
changed :-) 


Thanks for listening.  Now back to lurking...  

Dan O'Brien
Lucent Technologies (Bell Labs Innovations)
Columbus, OH  USA