From owner-freebsd-current Sun Jan 11 23:41:34 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11389 for current-outgoing; Sun, 11 Jan 1998 23:41:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA11384 for ; Sun, 11 Jan 1998 23:41:28 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 16538 invoked by uid 1000); 13 Jan 1998 07:42:06 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801120141.MAA00554@word.smith.net.au> Date: Mon, 12 Jan 1998 23:42:06 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: Firewall in kernel? - Found it! Cc: thyerm@camtech.net.au, current@FreeBSD.ORG, Studded@dal.net, kong@kkk.ml.org, Alex Nash Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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