Date: Tue, 13 Jan 1998 12:05:42 +1030 From: Mike Smith <mike@smith.net.au> To: shimon@simon-shapiro.org Cc: Mike Smith <mike@smith.net.au>, current@freebsd.org Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) Message-ID: <199801130135.MAA04371@word.smith.net.au> In-Reply-To: Your message of "Mon, 12 Jan 1998 17:21:11 -0800." <XFMail.980112172111.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801130135.MAA04371>