Date: Fri, 7 Jun 1996 14:12:45 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@sri.MT.net, hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD-current@FreeBSD.org Subject: Re: The -stable problem: my view Message-ID: <199606072112.OAA04073@phaeton.artisoft.com> In-Reply-To: <199606072008.OAA00297@rocky.sri.MT.net> from "Nate Williams" at Jun 7, 96 02:08:04 pm
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. 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). > 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. 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. > It is the policy of the FreeBSD project that *any* of the commits done > to the tree guarantee that the tree stays 'buildable'. However, this is > not strictly enforced (by the developers). However, with -stable more > care is taken to keep the tree 'buildable' than is generally taken in > -current, but that's due to the developers, not to the tools. If the developers won't enforce it, the tools and usage protocols should enforce it for them. That's the whole point of having a policy in the first place: to establish tree interaction protocols that don't have race conditions or holes in them. > The percentage of getting an 'unbuildable' tree due to the tools is > noise compared to the liklihood of a developer not doing ensuring the > tree is buildable. They aren't even in the same scope, with the > developer being responsible for 'unbuildableness' 99.9% of the time. Which is why the tools should force the developer to make the assurance. > > CVS can reconcile source trees (merge branch tags) just fine... we > > did that sort of thing at Novell with a CVS version of three years > > ago, no problems. > > No it *can't*. Don't tell me it can, because the trees have > *radically* diverted over the last 15 months to the point that CVS > *CAN'T* merge branches. It's *NOT POSSIBLE* to automate the process. This is a result of lack of discipline in terms of regularaly updating -stable. I think the confusion here is over what -stable is: is -stable a set of maintenance patches to the last -release, or is it a stable version of the -current tree? If the former, then it is unreasonable to expect it to contain all of the fixes that are in -current: specifically, *any* of the fixes that inhernetly affect system structure should *not* go into -stable. If the latter, then, what we are talking about is a mechanism for enforcing tagging of -current at synchronization points where the developers are known to have enforced the policy of "the tree must be buildable" (as you state, this is the responsibility of the developers to follow the checkin protocol that is being subverted). Pick one. > So, telling me otherwise is simply showing your ignorance of the *TRUE* > problem, which is *COMPLETELY* and *UTTERLY* unrelated to CVS's > ability or lack thereof of 'locking' the tree. CVS tree locking would force the developers to more closely adhere to the policy by limiting allowable tree interaction protocols that do not conform to stated policy. In other words, if the developers won't police themselves, the tools should force the policy upon them. I am open to other suggested soloutions (see below). > Please don't make me have to use my caps-lock key this much anymore. > You couldn't be more wrong about the issue. (Well, maybe you could, but > it would be hard and require serious intention to actually be wrong.) I think that you are misinterpreting my argument based on a former misinterpretation of the same argument in an earlier context, instead of taking it at face value in the current context. Instead of offering an implementation, perhaps you would be more comfortable with meta-discussion: ========================================================================== Inre: buildability of -current 1) -current is often not buildable 2) we posit this is disruptive, both to the developement and testing processes, and to the good name and faith of FreeBSD. 3) we posit that there are protocols, which, if obeyed, would cause -current to *always* be buildable 4) we evidentiarily conclude that these protocols are not being obeyed 5) we further conclude that IF the protocols are in fact as desirable as to cause their implementation, AND that the policy was, in fact, good policy, THEN some unspecified form of coercion causing developers to obey the protocols is ALSO desirable, given demonstrable failures of the existing non-coercive policy implementation Inre: buildablitiy of -stable 1) we generally acknowledge that -stable starts as -release, just as -current starts as -release 2) we posit that -stable is not buildable in approximately the same propotion to its change frequency (*not* rate) as -current is not buildable 3) we conclude that -stable may also benefit from enforcement of use of protocols designed to implement policy Inre: function of -stable 1) we acknowled the function of -stable to be as an intermediate tree, between -release and -current 2) we posit that the relationship -stable bears to -release vs. that it bears to -current is generally acknowledged to be indeterminate at this time, with cause cited as there being a dichotomy in administrative policy applied to -stable that has not been resolved 3) we posit that the relationship goals for -current and -release are conflicting, and that this is the source of the policy dichotomy 4) we conclude that the function of -stable needs to be defined, since it is meeting neiter relationship criteria to the general satisfaction of the parties involved 5) we note that one potential resoloution would be to eliminate the implied -stable/-current relationship entirely (as has been proposed by others) in favor of causing -current itself to fulfill that role by meeting the -stable buildability criteria, assuming the previously referenced problems are resolved first Implementation: TBD ========================================================================== Regards, 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?199606072112.OAA04073>