Date: Sat, 8 Jun 1996 15:40:58 -0700 From: "M.R.Murphy" <mrm@Mole.ORG> To: mrm@mole.Mole.ORG, terry@lambert.org Cc: freebsd-hackers@freebsd.org Subject: Re: The -stable problem: my view Message-ID: <199606082240.PAA19347@meerkat.mole.org>
next in thread | raw e-mail | index | archive | help
> > [ ... list trimmed to -hackers only ... ] > > > > 3) we posit that the relationship goals for -current and -release > > > are conflicting, and that this is the source of the policy > > > dichotomy > > > > What? > > That -stable can't bear the same relationship to both -current and > -release at the same time. Ahh. I _strongly_ agree. > > > Curent may build fine, but if it crashes or bumps, it doesn't make > > it as a stable system. As it should be. > > The grossest measure of stability is the ability to actually build > the thing. Things which do not build run expotentially less often > than things which build, but which are flawed. I agree that it's a gross measure. It's that only, though. > > The problem is that you're assuming, in the question, that -stable is > defined as -release plus selected fixes. I'd like to define it that way. I may easily be wrong, though. Whatever is defined, however, I think that a manageable set of bugfixes to a baseline release is a _good thing_. I think that's what a lot of folk would like. WRT a -current that builds, let that be my problem. If I don't save away -current when it builds, shame on me. (same for the present -stable, and in fact, shame on me, I got sloppy and didn't save the last one that built. Cost me work with ctm, but was I ever glad that it was available. Thanks rkw and others.) > > This is a fine definition, but it ignores: I thought it was a fine one meself. > > a) fixed are generally not modular little component plug-ins > which can substituted at whim. Source and header file > changes, at the least, are complexly connected. Yeah. It takes discipline to fix a release when the fun of the bleeding edge beckons. Kind of like embedding a really desireable patch in a much larger set of patches might drive some folks to distraction ;-) Cheap shot. I withdraw it. Don't shoot back. It's even more fun to take somebody's fix, extract the part that is suitable for a bugfix release, integrate, test, QC, ... not fun, I lied. Satisfying, though. > > b) When defined this way, -stable is acknowledged to be > "throw away code". You can't have your cake, and eat > it too. Either it is a stabilized -current, or it is a > more stabilized release... the goals are contradictory. Exactly, it is throw-away code, or "save it for history" code for pack rats. If it's a bugfixed of the current release, then that's what it is, no more, and no less. It is useful, though, while it has life. > > > > This is not just a FreeBSD problem. I haven't seen a single commercial > > vendor that manages to provide a solution to this problem that is worth > > a hill of warm horse manure. > > It requires electing an asshole. Or assholes, plural. And they don't even have to be elected. > > Specifically, someone willing to be an asshole if someone breaks the > source tree, until the source tree is fixed. You break the source > tree, the asshole lives in your mailbox until it is fixed. Even worse than that. Peer pressure. > > > Novell used CVS for the 6+ million lines of code for the NWU project, > in a single source tree, with more than 40 developers actively > stepping on the tree, using reader-writer locks. This was a source > tree which included protocol modules, router modules, system call > sets, context sharing extensions, and file system components -- not > to mention the large amount of user space code. Unlike the FreeBSD > source tree, it was not broken up into multiple source collections. > > The developement process was highly successful. I freely admit that > there was the sword of money hanging over the engineers on the project, > but even in excess of 100 man-years of stomping, the projects was > buildable on Solaris, SunOS, AIX, and UnixWare, on a nightly basis, > except for pre-specified lock-downs for code cutting, in all but 6 > occasions over the lifetime of the project. Money talks, doesn't it? :-) > > This is with 40 people spending 8 hours a day stomping the source > tree (via NFS, no less). > > The one ammendement to the locking protocol is the ability to force > idle locks out of the tree (which could of just as easily been > handled by inactivity timers, but we wanted to be able to flag a > lockdown for release, with only the release engineer making changes > to the overall tree -- he owned the lock). Done as many companies do it. And I don't know of a much better way. However, how much does any of this kind of software engineering help the end user who says to herself, "My system isn't working right. Do I have the right patches for it? Are the latest the right? Where are the patches anyways? Aieeeee, somebody wants me to install mega-patches and mini-patches and they conflict and the hell with it I'm going to go home and have a drink." DEC, HP, IBM, SGI, SUN, they all make life miserable with respect to updates, manditory and optional. Did I mention Microsoft? Or what I've done? Or how many other companies that do a similar job? I suggest that a -stable entity that acts as a bugfixed current release would be a good thing. A simple log of the fixes would be helpful, too, without having to use CVS. > > > I think that you'd be right in stating that it's *rare* to find a > commercial vendor capable of mounting a project in this fashion, > and to my knowledge, the majority of the group was broken up later, > but it's *not* unheard of. And there's no damn reason to accept > the status quo just because it is the status quo. > Agreed. I'd also suggest that it be kept simple. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > For this one I need the disclaimer, too. Nuts. My opinions in this posting are my own and not those of my present or previous employers. Obviously. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606082240.PAA19347>