Date: Mon, 12 Jan 1998 23:42:06 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Mike Smith <mike@smith.net.au> Cc: thyerm@camtech.net.au, current@FreeBSD.ORG, Studded@dal.net, kong@kkk.ml.org, Alex Nash <nash@mcs.net> Subject: Re: Firewall in kernel? - Found it! Message-ID: <XFMail.980112234206.shimon@simon-shapiro.org> In-Reply-To: <199801120141.MAA00554@word.smith.net.au>
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. > > It's not. > > In fact, even this thread is nothing new. There is a period of > reasonable stability and quiet in -current, then a few wrinkles and all > the people that were getting complacent start screaming. I was not screaming and I do not consider myself complacent either. 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. > 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. 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''. 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. 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. > 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. ---------- 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.980112234206.shimon>