From owner-freebsd-current Mon Jan 12 17:21:12 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA02771 for current-outgoing; Mon, 12 Jan 1998 17:21:12 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA02760 for ; Mon, 12 Jan 1998 17:20:27 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 13902 invoked by uid 1000); 13 Jan 1998 01:21:11 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801122344.KAA00315@word.smith.net.au> Date: Mon, 12 Jan 1998 17:21:11 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) Cc: current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 12-Jan-98 Mike Smith wrote: ... > I agree wholeheartedly that there is still plenty of room for > improvement; don't get me wrong on that one. My objections to your > proposals have more to do with what seems practical in the context of > the current development procedure. Agree. I was thinking about it in a different context. > I was considering this point as well; being able to cluster a group of > commits would be essential. > > Often you want to commit several sets of interrelated changes to widely > separated components in the tree; eg. consider changing a header > implementing a kernel interface (evil, yes, but let's consider it). > > You want to change the header, and the code in the tools that consume > it. You don't want to have to check out large slices of the tree, make > your changes and then commit the whole lot in one fell swoop. Instead, > you commit the changes to each tool separately. This is both a > convenience feature and also leads to more compact and relevant commit > messages. But, in between these commits, the tree is, by definition, broken. > In another case, imagine you have just made a minor commit to fix > something, and you make a typo. Normal procedure is to immediately > fix the fix. If you follow Julian's procedure, this would never happen. > There's another situation where you have two developers; #1 commits > code that is a prerequisite for #2's work. They may be on the phone to > each other, or whatever. A 3-hour wait for vetting would really slow > that sort of collaborative work down. In this case, developer #1 is the key holder, and #2 submits his/her changes to #1, which is now responsible for the whole transaction. Any other way, #2 may get there before #1 and break the tree. Can also ``work'' the other way around. > One more practical problem; count the number of commits in a day. > Multiply by 3 hours. If you want to serialise everything, that becomes > a real issue. This is where my superficial proposal really breaks. Using the compiler (and make) as a syntax checker is really bad. They are thorough but very slow and fragile. Something better and faster is needed. Sort of super-xref. ... >> 2. You prefer accuntability to procedure. >> >> I must admit that I accpt point 1 and agree with point 2. > > I'd agree with point #2 in this case simply because I feel that > accountability is more effective. If I could see how procedure could > be more effective I'd swap sides in an instant. Nah, procedure always gets implemented where accountability fails. By its nature, procedure fails too. ... > We seem to have a system which is working reasonably well. There is > historical precedent for resistance to any sort of change under the > circumstances. 8) Which is, in a way, a good thing. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313