Date: Tue, 13 Jan 1998 10:14:20 +1030 From: Mike Smith <mike@smith.net.au> To: shimon@simon-shapiro.org Cc: current@freebsd.org Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) Message-ID: <199801122344.KAA00315@word.smith.net.au> In-Reply-To: Your message of "Tue, 13 Jan 1998 12:28:39 -0800." <XFMail.980113122839.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> > Your proposal's not new either. Your offer to help run it is, but > >> > realistically do you feel that you have the time and stamina to do > >> > nothing but vet endless permutations of changes to the system? > >> > >> Done manually, yes, it will take a lot of time. Automated, it will not. > > > > Ah yes, the wonderful concept of "automated software testing". 8( > > Yuck. This is not what I had in mind at all. I was wondering aloud on the > need for automating some of these procedures. I have done it before, and > though maybe we need it here too. I don't know whether "we need automated procedures". 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. > > Given a buildable state A, and desired target state C, how do I transit > > between the two when it is necessary for me to make more than a single > > commit? After the first commit I have an unbuildable but temporary > > state B, which your system will reject. > > Why is it necessary to make more than a single commit to transition from > given to desired? Just curious. I am looking at this whole thing as a > dtatabase transaction, whith a clear BEGIN, checkpoints, and COMMIT. Maybe > your point B is a checkpoint, meaning ``I want the change to `take' even if > the transaction is to fail''. 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. 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. 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. 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. > > And an automated buildability checker will help here? One with > > 'buildworld' latency? Why not educate the developer population instead? > > Rather than frustration and rejected commits, you get increased > > productivity and happier hackers. > > You are raising two interesting points, which Julian already did. > > 1. We are willing to risk occasional breakage in the name of speed. > > 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. > > Why is it that prohibition is so much easier to advocate than > > commonsense? > > Because prohibition is procedural, ``fair'', anonymous and non-personal, > thus, once agreed to, much easier in our society. "path of least resistance" I guess. > Agree. I was not proposing an implementation. Just probing for > acceptability of a concept. > > Seems to me I was proposing a solution to a non-problem. No, at least not to me. I felt you were proposing a non-solution to a problem.a > Seems to me that we, by all accounts, have a great system wich does not > require improvement at this time. No sarcasm here, really. 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) -- \\ 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?199801122344.KAA00315>