From owner-freebsd-current Sun Feb 22 06:40:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA03164 for freebsd-current-outgoing; Sun, 22 Feb 1998 06:40:26 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA03159 for ; Sun, 22 Feb 1998 06:40:25 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id HAA10768; Sun, 22 Feb 1998 07:40:24 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id HAA24031; Sun, 22 Feb 1998 07:40:22 -0700 Date: Sun, 22 Feb 1998 07:40:22 -0700 Message-Id: <199802221440.HAA24031@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), current@FreeBSD.ORG Subject: Re: More breakage in -current as a result of header frobbing. In-Reply-To: <199802221205.FAA29448@usr07.primenet.com> References: <199802220518.WAA22819@mt.sri.com> <199802221205.FAA29448@usr07.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Your 'global' lock does *NOTHING* (!!!!!!!!!) to make the tree any more > > buildable > > No. But it makes it obvious that it was *you* that did it. No more so than the current behavior. It is known *now* who breaks the tree, since breaking the tree is related to the commit, not the lock. > And if you do it consistently, you *should* lose your priviledges that > allow you to do it. Nobody is willing to brandish the 'lose your priviledges' stick. ;( > > Sometimes your absolute silliness appears to be a lack of intelligence > > at times. > > I think you don't understand the concept of environmental enforcement > of desirable behaviour. FreeBSD is free to choose whatever environment > it wants, within the scope of physical laws. Including an environment > that punishes tree breakage, if it's smart enough to do so. Sure I do, but a feedback loop is related to the feedback, and if you add steps in the process that are unrelated to the feedback loop, you're not doing anything to change the feedback, just adding more noise to the system. Aka. Sticking llamas in the office doesn't make the programmer want to do good commits, but telling them to do so 'or else' (with a backed up 'or else') does. 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. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message