Date: Fri, 7 Jun 1996 14:59:14 -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: <199606072159.OAA04189@phaeton.artisoft.com> In-Reply-To: <199606072127.PAA00653@rocky.sri.MT.net> from "Nate Williams" at Jun 7, 96 03:27:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. I agree. > > 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. Policy would dictate that the developer responsible would get hate mail from everyone who *did* follow policy, and was unable to commit as a result of the first developers actions. > > 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. This can happen because, while I am ensuring buildability prior to doing my commits, another developer can be doing commits, and invalidate all of the work I have just done to provide my assurances. There is little incentive for me, as a developer, to do work that will likely be ineffectual, even if it's "policy". > > 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. Only because we allow simultaneous checkins so that the complexity of ensuring the tree is buildable is an order of magnitude higher than it needs to be. In reality, common usage will dictate that the tree is checked out of *vastly* more than it is checked into, so a checkin serialization that doesn't affect checkout is probably desirable. The side benefit that you could know that the tree was not in a partially inconsistent state (in the middle of a checkin) at the time you do your checkout is also worthwhile, especially for producing consistent SUP/CTM images of the CVS that maintain the same policy guarantees as the main tree. You *could* choose to checkout while a write tag was in force, or to checkout without asserting a read tag, allowing a write to occur in the middle of your checkout, leving you with an inconsistent tree. But you would have to consciously do so. > 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 isn't true. The developers doing checkin would need to jump through the additional hoop of assuring us that they were not turning the tree to shit (effectively). This is something policy says they should be doing anyway. > This is counter-productive to the entire 'FreeBSD' philosophy. Providing high quality free software? > 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. As long as you are using the current tools, I'm wasting bytes. As far as "hiring everyone and forcing them to play by the rules using reactive enforcement", it's silly. Even if I could hire everyone, I'd still implement a *proactive*, NOT *reactive*, system for policy enforcement. If I *did* hire everyone, the first thing I'd do would be to merge the FreeBSD, NetBSD, and OpenBSD efforts together to increase gross efficiency, not diddle around with policy models to increase net efficiency... I'd save that diddling for later. Since I can't do this, and I realize that you can't force volunteers to work together like you can force employees (with a whip made of money to use as a tool), I'd like to diddle with increasing net efficiency in FreeBSD. Especially now that you and others have haised the issue in the first place. > The benefits of 'forcing' commits to be always buildable do not even > come close to touching the costs involved. All I have ever suggested was configuring the tools in such a way as to force adherence to *some* aspects of policy. Obviously, I can't force use of consistency protocols down the line (as you point out, the cost of compilation for a commit makes the very idea humorous), even if I was declared "tool god" for the time needed to implement the protocols in the tools. If something like this could resolve the -stable relationship with -release vs. -current, or if it could increase the overall usability of the -stable and -current CVS trees for SUP/CTM consumers, it would be well worth the effort. You can't build a house with a hunk missing out of the foundation, and the point of FreeBSD is to provide a platform for others to build things, *as well* as allowing people to hack on the platform itself. It's as much for the people building the houses as it is for the people pouring the foundations. 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?199606072159.OAA04189>