Date: Tue, 13 Jan 1998 12:28:39 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Mike Smith <mike@smith.net.au> Cc: Alex Nash <nash@Mcs.Net>, kong@kkk.ml.org, Studded@dal.net, current@freebsd.org, thyerm@camtech.net.au Subject: RE: Commit Approval (was Re: Firewall in kernel? - Found it! ) Message-ID: <XFMail.980113122839.shimon@simon-shapiro.org> In-Reply-To: <199801121334.AAA00363@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12-Jan-98 Mike Smith wrote: ... >> > 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. >> Besides, I am already doing that. All I was proposing is to have a >> go/fail >> mechanism that serializes all requests and simply rejects those that >> fail >> to ``make buildworld''. > > 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''. > 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. > 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. >> Think about it as an ATM deposit into your checking account; It is not >> there officially until the transaction is verified, but you can deposit >> and >> forget. If you made no mistakes, the transaction becomes official. If >> not, you are told there is a problem. For ``correct'' CVS transactions >> this represents a delay of few hours. For bad transactions, it acts as >> an >> early warning system and reduces noise in this very list. > > That's an awfully big handwave there; counting a few notes is just ever > so *slightly* easier than verifying the real buildability of a commit, > let alone its correctness. 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. > As for noise on the list, that's not going to go away, or even reduce > much, just by removing the (really pretty rare) "-current build fails > with xxxxx" messages. Again, I must agree this is a ``noisy'' list. Probably its main attraction to many :-) > The current mechanism works amazingly well, and has shown a strong > improving trend over the last couple of years. Nuking it would be a > real Dilbert manouvre IMHO. Seems to me that we, by all accounts, have a great system wich does not require improvement at this time. No sarcasm here, really. So, my ``proposal'' was unnecessary and is thus dropped. ---------- 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.980113122839.shimon>