Skip site navigation (1)Skip section navigation (2)
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>