Date: Fri, 7 Jun 1996 15:27:15 -0600 From: Nate Williams <nate@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 Message-ID: <199606072127.PAA00653@rocky.sri.MT.net> In-Reply-To: <199606072112.OAA04073@phaeton.artisoft.com> References: <199606072008.OAA00297@rocky.sri.MT.net> <199606072112.OAA04073@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The main argument against "let's get rid of -stable" is that -stable > > > is known to be buildable. If -current were known to be buildable, > > > it would support the argument for getting rid of -stable. > > > > No, the main arguement is that -stable is known to be -stable. -Current > > is almost always (95%) 'buildable', but it's not necessarily 'stable'. > > Current contains 'experimentable' (aka. known to be unstable) changes in > > it that stable doesn't (shouldn't) have. Heck, the tree would be > > buildable if the compiler wouldn't quit dumping core on you. :) > > Regrettably, -current has had long bouts of it being unbuildable. The > most recent (two week long) bout involved yacc build rule changes. > There have also been partial commits of header file changes. Due to the developer not doing his job. > The problem is the result of the partial commits, not the result of > any inherent instability in -current (barring things like large VM > commits, which are going to be destabilizing of -stable if -stable > ever includes them as a reintegration). Yes, it was due to the developer not finishing the job that was started. If the tree was locked down at the start of the commit, and then unlocked after the commit finished the job would still not be done. If I only do 50% of the job in one day, the remaining 50% still needs to be done, no matter what kind of tools I have. > > > As a matter of fact, the difference of the ability of 'stable' > > vs. 'current' regarding it's buildable state has *ABSOLUTELY NOTHING* to > > do with CVS in *ANY SHAPE OR FORM*. 0, nada, zip, nothing! > > 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. > In other words, if a CVS tree can never be "check-out-able" and > "unbuildable" at the same time, it will never be possible to have > a checkout *not* build. Then *FORCE* the developers to *NEVER* check in changes which cause the tree to be unbuildable. That's the *only* solution. There is no other solution to the problem, and locking the tree down during the commit won't make it any more buildable. You have to *FORCE* the developers to only make changes which keep the tree buildable, and this is a problem whose scope is beyond the resources of FreeBSD. Changing to tools to force the developers to keep a buildable tree 'simply won't happen'. Period. End of discussion. The resources aren't there, and I doubt the developers would stand for it in any case because anything your tools do to enforce policy can be circumvented and generally only cause the developers more grief to 'jump through hoops' to get code accepted. This is counter-productive to the entire 'FreeBSD' philosophy. Now, if you want to hire all of us and dock our pay if we check in un-buildable changes then go for it, but until there is a compelling reason to 'do my best' to keep the tree buildable with the current tools then you are wasting bytes. The benefits of 'forcing' commits to be always buildable do not even come close to touching the costs involved. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606072127.PAA00653>