From owner-freebsd-hackers  Fri Jun  7 15:26:13 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA28972
          for hackers-outgoing; Fri, 7 Jun 1996 15:26:13 -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 PAA28966;
          Fri, 7 Jun 1996 15:26:09 -0700 (PDT)
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id QAA00983; Fri, 7 Jun 1996 16:24:49 -0600
Date: Fri, 7 Jun 1996 16:24:49 -0600
From: Nate Williams <nate@sri.MT.net>
Message-Id: <199606072224.QAA00983@rocky.sri.MT.net>
To: Terry Lambert <terry@lambert.org>
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: <199606072215.PAA04267@phaeton.artisoft.com>
References: <199606072207.QAA00896@rocky.sri.MT.net>
	<199606072215.PAA04267@phaeton.artisoft.com>
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > 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.
> 
> Look, I hate coming back to the recent yacc stuff because it makes
> it look like I'm pointing fingers, but it's just the most recent
> example in a long line of examples that belie your statement.

Poul didn't finish what he started.  That was bad, but the locking
protocol of CVS wouldn't have done anything to solve that problem.  The
only way to solve that problem is to either build in enough smarts into
the tool so that you *can't* commit code that causes the tree to break
(basically impossible given the current resources), or have the
developers police themselves and use 'people' to enforce the rules.

The issue you brought up was the somehow CVS locking would solve part of
the problem, so it's irrelevant to the problem at hand re: -stable
vs. -current.

No more shall be said by me since all that needs to be said has
been. (and then some).



Nate