Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Aug 1996 22:16:13 -0700
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Terry Lambert <terry@lambert.org>
Cc:        rkw@shark.dataplex.net, p.richards@elsevier.co.uk, hackers@freebsd.org
Subject:   Re: Am I wrong or is this just stupid?r 
Message-ID:  <2853.841209373@time.cdrom.com>
In-Reply-To: Your message of "Tue, 27 Aug 1996 16:10:43 PDT." <199608272310.QAA25610@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> I have to say that what Robert wants is a top-down design process, where
> you agree on the problem, you agree on the general principles of the
> soloution, and you agree to ignore the implementation details below that
> scale.

This works for some things, and I don't dispute the *general* merit of
such design methodology, but we still have to deal with certain real
world constraints.  In this particular case, I don't see any merit in
instigating a discussion where some 10 or 15 messages will be devoted
to putting forward different proposals from various people with their
own pet design strategies, 30 messages will be devoted to knocking
down those proposals in various ways, another 100 messages will be
wasted in irrelevant threads generated by people who don't actually
understand the subject but feel compelled to comment anyway and a
final 200-300 messages from people letting the 2nd group of folks know
that they don't know their arses from their elbows.  Conservatively
speaking, that's at least 400 messages which won't get us one iota
further towards solving the problem.

I'd prefer to simply see the prototype and thus constrain the ensuing
discussion to more practical details.  Most people just aren't
adequately taking into account the fact that we HAVE been discussing
the make system on and off for over 3 years, and discussion alone has
accomplished very little.

> It is very helpful to me, as an engineer, to get a firm "here is the black
> box" from marketing.  It is also good if I can get an agreement for them
> to not second-guess my work in terms of their new "requirements", generated
> since they made the agreement.

There are many tried-and-true techniques from industry that just don't
translate well to the FreeBSD project and can't without creating the
kind of "accountability hierarchy" that only paying people salaries
can provide.

To use a military analogy, if I've got access to weapons and a team of
trained soldiers, I can make a number of assumptions regarding their
ability, coordination and effectiveness at taking a given objective.
Now replace those trained soldiers with a team of volunteer irregulars
with widely varying abilities and I'd sure better toss those
assumptions right out the window and modify my assault plan
accordingly if I'm to still have any hope of taking that objective.

I've had 3 years with this project, seeing which techniques can be
brought straight across from industry and which don't have a
snowball's chance in hell of working out for us, and I can say that
some of what Richard wants is simply not practical, nor is it likely
to become so in the near future (if ever).  If he's truly sincere
about wanting to effect reak change here then he's going to have to
alter his approach to fit the model which has evolved here.

> Richard really can't ask for this without offending people, since he is
> asking for a fiat, effectively: he wants it acknowdleged that if he takes
> it on, it's his bailiwick, to do with as he pleases.

Anyone is free at any time to do what he damn well pleases with the
system, just as the development team and the users are free to adopt
it or not (and, contrary to popular belief, the users have just as
much power as the developers do here - if they reject something and
refuse to use it, it invariably withers and dies just as surely as it
would if a developer killed it).  I can no more give Richard a "fiat"
as I could block him from changing this part of the system and
distributing his own diffs, even using our own announcement lists to
reach his intended audience.  The sword cuts both ways!

> Probably, he would be better off contacting the core team directly for
> that kind of assignation.

Or finally realizing that "assignation" is not how it works at all,
nor has it ever worked that way.  People "take charge" of sections of
the system simply by working on them, just as I have for the
installation, Garrett has for networking, John & David have for the VM
system, etc.  That's it, that's how it works.  Do the work and the
rest follows.  Sometimes an area of the system is already "spoken for"
and people have to share the responsibilities and/or coordinate
closely with others if they want to join in, but it's still the
quality and quantity of tangible work, submitted over a reasonable
period of time, which leads to the other developers trusting someone
implicitly to handle large parts of FreeBSD development.

						Jordan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2853.841209373>