From owner-freebsd-current Sun Feb 22 17:53:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22867 for freebsd-current-outgoing; Sun, 22 Feb 1998 17:53:24 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22856 for ; Sun, 22 Feb 1998 17:53:20 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id SAA06818; Sun, 22 Feb 1998 18:53:19 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd006795; Sun Feb 22 18:53:14 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA17096; Sun, 22 Feb 1998 18:53:12 -0700 (MST) From: Terry Lambert Message-Id: <199802230153.SAA17096@usr08.primenet.com> Subject: Re: More breakage in -current as a result of header frobbing. To: nate@mt.sri.com (Nate Williams) Date: Mon, 23 Feb 1998 01:53:12 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199802221440.HAA24031@mt.sri.com> from "Nate Williams" at Feb 22, 98 07:40:22 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > FreeBSD's problem is that everyone has 'broken' the tree enough times > that no-one is willing to brandish the 'big stick' to whack people for > making bad commits. If you've got no negative feedback, then you've got > no reason to test changes. I think that "the big stick" approach is fundamentally flawed; that's why I think the software should be doing the procedural enforcement, so that "the big stick" is unnecessary. You have my suggested method of enforcing a procedure that results in a buildable tree. Personally, I'm not hell-bent on reader/writer locks; I just know that they are one method which would tend to work, especially if the lock release required a build-step before it would release (no, not a "build world", unless the dependencies can be fixed). Feel free to suggest other alternatives for software enforcement of buildability; like I said above, I'm not necessarily wedded to the lock idea -- it's *a* soloution, not *the only* soloution. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message