From owner-freebsd-current Wed Sep 4 10:22:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA21958 for current-outgoing; Wed, 4 Sep 1996 10:22:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA21948 for ; Wed, 4 Sep 1996 10:22:45 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA06682; Wed, 4 Sep 1996 10:13:19 -0700 From: Terry Lambert Message-Id: <199609041713.KAA06682@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 4 Sep 1996 10:13:19 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, rkw@dataplex.net, current@freebsd.org In-Reply-To: from "Michael Hancock" at Sep 4, 96 10:11:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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.