Date: Mon, 12 Jan 1998 00:36:09 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Simon Shapiro <shimon@simon-shapiro.org> Cc: current@freebsd.org Subject: Re: Firewall in kernel? - Found it! Message-ID: <Pine.BSF.3.95.980112002449.15549E-100000@current1.whistle.com> In-Reply-To: <XFMail.980112234206.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Jan 1998, Simon Shapiro wrote: > > 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. The problem is that I the users committing should have done test builds directly defore/after committing. at least testing all related areas. I think it's one of those things where the cost of living with the confusion is more than the cost of stopping it. (see later) > > 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. Yes but it would slow down my own verification of the correctness of my patches.. My method is: edit/build/test/edit/build/test make world (not always fora a smaller commit) cvs diff apply diff to my commit tree commit (remotly) cvsup to local cvs tree <-------XXX checkout entire sources make kernel(s) make world this way I catch any stuffups You are suggesting inserting a 3 hour gap at XXX this will slow down my attempts at checking my commit. (that will really slow down my work rate, as I can't really get on with other things till I see my own commits return. (I don't multitask well) > > 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. It aint purfect, but it's remarkable how effective it is. this last week has been an aberation rather than the norm. I'm usually pretty happy with the state of the tree really. julian (ps. new devfs code out..)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980112002449.15549E-100000>