Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Sep 1996 10:13:19 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        michaelh@cet.co.jp (Michael Hancock)
Cc:        terry@lambert.org, jkh@time.cdrom.com, rkw@dataplex.net, current@freebsd.org
Subject:   Re: Latest Current build failure
Message-ID:  <199609041713.KAA06682@phaeton.artisoft.com>
In-Reply-To: <Pine.SV4.3.93.960904094546.7641B-100000@parkplace.cet.co.jp> from "Michael Hancock" at Sep 4, 96 10:11:54 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > At Novell, using CVS with a reader/writer lock front end, we were
> > able to keep a project with 18+ engineers hacking on it 8-12 hours
> > a day buildable for every night but 5 for a period of 8 months.
> > Further, we did it on three machine architectures.
> 
> With fulltime engineers in how many time zones?

Three.  Utah (MST), Texas (CST), and New Jersey (PST).  We also had
two engineers on GMT (England), but they worked by rlogin into the
New Jersey site (transatlantic timesync was a problem).

Further, the CVS tree was NFS mounted on the engineers boxes, and they
were timesynced to the NFS server's clock.

If you don't NFS mount the CVS tree, the timesync/rlogin problem goes
away.

> FreeBSD which has volunteers working in multiple timezones.  The current
> model is a good fit for this situation. 

It is a fit.  It is not "the optimal fit", which is what this whole thread
has been about -- system engineers, like me and Richard, compalining about
the process itself not being meta-engineered.


> The problem is that there isn't a good alternative to current for people
> who expect a buildable tree.

This was one soloution I suggested; internalize -current using a
modification of Jordan't "build cookie" approach, to get away from
6 out of 7 machines claiming "well, it built fine for me".  The
only difference between that and the existing situation is that
it would be machines posting in cookie space instead of humans
posting on -current -- that is, they are topologically equivalent.


> The focus should be put on an automated way of providing a buildable tree
> and advertising it as the tree that most people should be downloading. 

Yes, I agree.  The problem with the current discussion is not the
abundance of discussion, it's the lack of implementation.  This is
the same problem that hits every 3-4 months.

Novell had this same problem: they are a large company that want's
to be a small company.  Each time they acquire a company, they
institute lay-offs until the number of employees drops below the
critical mass at which "the good ol' boy network" method of working
fails.  They do this to kickstart "the good ol' boy network" back
into usability.  They do the same thing in many different ways.  They
do it by centralizing accounting, payroll, and other services, to
reduce their mass.  More recently, they moved many of their employees
to a central campus, the better to increase the maximum head cound
before the G.O.B.N. breaks down, again.  They are unwilling to change
their model to accomodate their growth, and so their growth fails.
One possible soloution for Novell is "the holding company" approach.
If I own all companies in a given market segment, it's really
irrelevent if they compete: I am making all of the money to be made
in that market segment, not matter how I am organized.  So I should
chose the organization with the best stability for the conditions
instead of trying to use my hammer to turn every organization into
a nail.

The "core team" methodology is a single tier G.O.B.N.; it differs
from the Novell G.O.B.N. only in scale, and only then because the
incentives in a volunteer effort are less than those in a commercial
effort (something the GNU idealogues do not apparently understand).
The relative critical mass of a G.O.B.N. before it fragments under
unternal pressure is directly proportional to the strength of the
incentives involved.

It is unprofessional to have to rely on someone to do something because
"they are your buddy" as opposed to relying on them to do something
because "it's their job to do it".

In a volunteer effort, the line is more fuzzy, but it is still there.
People get involved in a volunteer effort for "payment".  It is not
worth discussing whether this payment is real, and comes from Walnut
Creek or whereever, or whether it's more ephemeral.  The fact is that
there is payment, and the payment should be sufficient to incent people
to do what they need to, and ought to, do.

The problem with the G.O.B.N., which is already in place, is twofold:
it's inertia from already being in place, and the reluctance of the
"insiders" to adopt a model which is more favorable to the groups
goals than to their personal goals.


The problem is the model.  You will not make the problem go away by
making the model operate to a higher critical mass; you will only
increase the pressures, and the resulting explosive force when the
critical mass is exceeded.


					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?199609041713.KAA06682>