From owner-freebsd-current Fri Jun 7 15:09:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27677 for current-outgoing; Fri, 7 Jun 1996 15:09:17 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA27635; Fri, 7 Jun 1996 15:09:09 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id QAA00896; Fri, 7 Jun 1996 16:07:47 -0600 Date: Fri, 7 Jun 1996 16:07:47 -0600 From: Nate Williams Message-Id: <199606072207.QAA00896@rocky.sri.MT.net> To: Terry Lambert Cc: nate@sri.MT.net (Nate Williams), hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD-current@FreeBSD.org Subject: Re: The -stable problem: my view In-Reply-To: <199606072159.OAA04189@phaeton.artisoft.com> References: <199606072127.PAA00653@rocky.sri.MT.net> <199606072159.OAA04189@phaeton.artisoft.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Again, with respect, if it is impossible to check out from a tree > > > until usage protocol (*not* CVS implementation) guarantees that > > > the tree is buildable, and the same usage protocol prevents a > > > checkin that isn't self-conssistent across all files in the archive, > > > then the tree will *ALWAYS* be buildable, period. > > > > This is basically unenforceable at the tool level. The amount of work > > required to do the 'lint/build/test/etc' *AT* commit time is so beyond > > the scope of the entire project as to be humorous. > > I am not suggesting enforcing this at the tool level; I'm suggesting > that the tools should be set up so that this is the "natural" result > of their proper use. > > Right now, it is possible to properly use the tools in accordance > with policy and end up with an unbuildable tree. Yes, but only if the developer isn't paying attention. This has happened less times than I can count on two hands. Considering that we're probably approaching hundreds of thousands of commits since we've started, I'd say we're doing pretty well and that nothing needs to change as far as that part of commit process goes. Nate