Date: Tue, 13 Jan 1998 00:04:23 +1030 From: Mike Smith <mike@smith.net.au> To: shimon@simon-shapiro.org Cc: Mike Smith <mike@smith.net.au>, thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org, Alex Nash <nash@Mcs.Net> Subject: Commit Approval (was Re: Firewall in kernel? - Found it! ) Message-ID: <199801121334.AAA00363@word.smith.net.au> In-Reply-To: Your message of "Mon, 12 Jan 1998 23:42:06 -0800." <XFMail.980112234206.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On 12-Jan-98 Mike Smith wrote: > >> > >> It does seem that we have, as of late, a situation where submitted > >> patches > >> do not even compile. This particular one is not the first, but maybe > >> for > >> some of us, one too many. > >> > >> There can, logically, be only two explanations for this trend: > > > > You are making the fallacious assumption that this is a "trend" or > > something somehow new. > > You are assuming I make an assumption, which I am not. I can't imagine what else you might be doing. It's certainly not an observation, as it has no basis in any observable fact or history, and I was being too polite to suggest you were delusional... 8) > I belive every process which shows failure can be improved, and any human > process that does not show failures is so broken that failures do not even > show up. No argument there. > > 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( > 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. > This instead of today's mechnism, where sources > that do not make sense even to GCC and /bin/sh are becoming part of the > official tree, only to be retracted/modified. 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. Why is it that prohibition is so much easier to advocate than commonsense? > 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. 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. Sheesh, you should go back a little while and look for the times when people would post saying that -current *built*. > > We already *have* a lazy vetting system, with many hundreds if not > > thousands of participants, and a reasonably adequate feedback > > mechanism. Trying to improve substantially on this would require a lot > > of work. 8) > > If the concensus is that the current system is oh so very well, and needs > no further improvement, then I humbly apologize and withraw my offer. To be completely blunt about it, and bearing in mind that this is just *my* opinion, there are many things that would benefit more from the sort of effort and attention that would be expended on such a scheme. 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. -- \\ 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?199801121334.AAA00363>