Date: Sat, 8 Jun 1996 14:53:17 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mrm@Mole.ORG (M.R.Murphy) Cc: freebsd-hackers@freebsd.org Subject: Re: The -stable problem: my view Message-ID: <199606082153.OAA08455@phaeton.artisoft.com> In-Reply-To: <199606082111.OAA19115@meerkat.mole.org> from "M.R.Murphy" at Jun 8, 96 02:11:14 pm
next in thread | previous 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. > 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. The problem is that you're assuming, in the question, that -stable is defined as -release plus selected fixes. This is a fine definition, but it ignores: 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. 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. > 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. 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. 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. 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). 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. 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?199606082153.OAA08455>