Date: Wed, 4 Sep 1996 20:47:46 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: msmith@atrad.adelaide.edu.au, rkw@dataplex.net, nate@mt.sri.com, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <199609050347.UAA08103@phaeton.artisoft.com> In-Reply-To: <199609050234.TAA02038@root.com> from "David Greenman" at Sep 4, 96 07:34:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >If your plan works, more will join the bandwagon. If it sinks, we don't go
> >down with you.
>
> It may or may not be obvious, but there is only one significant reason why
> we ("we" being the people who are responsible for the distribution of FreeBSD
> in its various forms) resist change. The simple fact it that we're already
> loaded to the limit of the amount of work that we can do, and thus the
> prospect of changing the current model to one that is even more complex than
> what we're doing now does not at all sound appealing. We don't have the time
> for this. It's arguable if the new scheme would even be of significant benefit.
> Please realize that I'm sure it would be of significant benefit to you
> personally and perhaps to some larger set of people, but as always, we have to
> look at the big picture and balance our resources to satisfy the largest
> number of people with the effort that we expend. It has to be this way for
> both practical and pragmatic reasons.
Where would nay thread be without its car analogy? 8-).
Actually, it's a significant investment to move from your existing car
(which is a 1974 Chevy Mailbu that gets 8 miles to the gallon) to the
new Geo Storm (which gets 36 miles to the gallon). However, having
moved, you free up resources which were otherwise being consumed to
maintain the status quo.
I think the gist of the discussion (the one I think I've been having,
anyway 8-)) is intended to *offload* the burden from you, Jordan, and
others, and to put the burden on the process.
This is a fractal complexity issue. If it becomes overall more complex,
but it becomes orthoganal at the same time, you can reduce your management
overhead to only consider the top fractal dimension. The process, if
built corectly, will force everything else to fall into line.
This helps to solve your problem -- not adds to it. At the same time,
it resolves some of the nagging issues that come up once in a while,
as a side benefit -- the comparison of process to that of the Linux
camp, for one.
> However...like Michael just suggested, nothing prevents you from setting up
> such a framework for a "-recent" distribution. If you come up with a model
> that works, we might even arrange for it to be replicated in various places
> to increase the distribution potential. The key here is that you are (from
> my perspective anyway) trying to force us to adopt some personal grand plan
> of yours and even if it was a good idea, trying to get us to do more work
> through coercion is entirely the wrong approach and you should expect your
> efforts to fail.
I think he wants you to vet a process change, in the same way a comitter
or core team memebr must vet code before it is checked in. Processes
are ephemeral things which are whatever a group can agree they are.
The anti-change inertia can function as a firebreak; but it can also
function to help you shoot yourself in the foot.
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?199609050347.UAA08103>