From owner-freebsd-current Mon Jan 12 17:44:48 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06180 for current-outgoing; Mon, 12 Jan 1998 17:44:48 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA05761 for ; Mon, 12 Jan 1998 17:42:50 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA04371; Tue, 13 Jan 1998 12:05:42 +1030 (CST) Message-Id: <199801130135.MAA04371@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , current@freebsd.org Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) In-reply-to: Your message of "Mon, 12 Jan 1998 17:21:11 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 1998 12:05:42 +1030 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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. That's correct. In most cases, such breakage works in the current system, assuming: - the breakage is fixed quickly (next commit(s) come soon), leaving the window in which someone else will be hurt as narrow as possible. - consumers are prepared to retry before complaining. I agree that we get by on probability rather than certainty. The more I talk about it, the shakier it sounds. 8) > > 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. True. However often enough a one-line fix is easier to type than to ship a diff around for, or it works in the context in which you have tested it but fails in a larger one. The "test it here first" process is definitely what all responsible developers should use. Always. *blush* > > 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. That works, to a degree, too. It breaks down in terms of accountability though, in that #1's name is on #2's changes. There are lag and synchronisation issues too, not to mention the extra overhead for #2 to transfer all the brain state involved in their changes to #1. > 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. *grins* I'll take three, please. > > 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. Ouch. For someone a few messages ago so hot on procedure your cynicism is scalding. 8) > > 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. Perhaps. I am often concerned that we have a little too much inertia, but such a thing is very difficult to judge. Where does caution become conservatism, and conservatism become NIH or worse? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\