Date: Fri, 7 Jun 1996 23:03:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@sri.MT.net, michaelh@cet.co.jp, hackers@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-current@freebsd.org Subject: Re: The -stable problem: my view Message-ID: <199606080603.XAA05574@phaeton.artisoft.com> In-Reply-To: <199606080535.XAA02830@rocky.sri.MT.net> from "Nate Williams" at Jun 7, 96 11:35:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > It's like making a loop that gets called once at initialization time 50% > > > faster while you leave the sorting algorithm which takes up 95% of CPU > > > time alone. It's doesn't buy you anything but a warm fuzzy feeling. > > > > This is *not* an issue of "optimizing the boot code". > > > > This *is* an issue of removing the potential for developer checkin > > conflict, so that the only margin for error is that of the developer > > who disobeys protocol. > > But we don't have a problem with checkin conflict. It's simply a > non-problem. If it ain't broke, don't spend alot of time fixing it. > > How many times do I have to say this? Until -current builds with no errors that can't be traced to a policy violation (and a specific violator) for a period of one month. > > The net results are that the claim "merge cascade failure" is no > > longer a valid excude for an unbuildable tree. If Jim-Bob makes > > the tree unbuildable, it's obvious that Jim-Bob is a protocol > > violator. If he does this a lot, then there should probably be > > a policy enforcement decision by "the grantors of tree access" > > to prevent future offenses. > > It's obvious now who breaks the tree. We don't need CVS to tell us > that. If "committer #1" checks in changes to modules A, B, C, and Q, and "committer #2" cheks in changes to modules X, Y, Z, and Q, and there is a cumulative conflict, who is at fault if their access was not serialized? Answer: the tools. > > The intended effect is a buildable tree and identifiable culprits > > in the case of a non-buildable tree. > > Since it won't help the former and the latter is already a known, what's > the point? You are wrong that it will not help the former. The latter is largley irrelevant as anything byt a disincentive to violate protocol, something your argument "former" implicitly assumes as one of its axioms. I will not buy your axiom, even if you phrase it this way. It is a bogus axiom. > Jim-Bob and John-Boy *don't* make changes to the tree simulateously. I > suppose if we had another couple hundred committers we might have this > problem, but we don't. > > CVS == Concurent Versions System > > It allows concurrent access to the tree my multiple-writers *BY DESIGN*. > > It's NOT BROKEN anywhere except in your mind. It *WON'T* fix any > problems that are of any significance in the FreeBSD build tree. It fixed them for the NetWare for UNIX source tree. This is historical fact. Are you arguing that history is not applicable to the current situation? What about the proposed test (which you deleted from your reply)? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606080603.XAA05574>