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