On Wed, 27 Feb 2002, George V. Neville-Neil wrote:

> I think we need to avoid the concept of "imposing some modicum of
> structure."  If we create structure it is because we need it.  Just like
> software.  There was a good comment recently about "software gets
> created to scratch an itch."  I'd say that structure gets created
> because you're tired of losing fingers and toes to the person next to
> you wielding the axe.  It's great that your friends are helping you
> clear the forest but you'd all like to be able to walk and pick up your
> cup of coffee at the end of the day as well.

What I mean by "imposing structure" is:

- Identify patterns of development and structure that seem to have evolved
  naturally as part of the maturing of the FreeBSD Project
- Determine which patterns tend to result in the most productive and
  parallel development efforts, not to mention which are the most popular
- Selectively reinforce those patterns to improve the ability of
  developers to rely on the patterns

An example of this might be investment of time in a rote API change: such
changes are time-consuming requiring a lot of brute force source code
modification.  There's a strong motiviation to avoid redundant work here,
but frequently the work is necessary, so it's also desirable to know that
it's going to happen.  A normal model here might be to look for a
developer who's willing to do it, and wait for them to come back in a week
or two when it's done.  An unproductive tendancy is for four developers to
go off, and do the work over two weeks, and all discover they've done it
at the end.  This can be avoided by making an attempt to coordinate.  On a
small scale and for individual cases, the "problem" here can be lived
with.  When it's in the context of a larger piece of work, it can be
highly counter-productive.  One reinforcement that could be made is to
encourage developers to indicate what works in progress they have going,
and to encourage other developers interested in a change to give that list
a skim to see if someone else has already started on it, and if someone
has but appears to be timing out, to encourage them to talk to the
developer who has claimed it (in some sense) to find out what is going on.

> We are always going to have "first past the post" problems.  If someone
> comes along and has rewritten a whole subsystem, and testing and
> performance measurement show that it's an order of magnitude better
> (faster, smaller, etc.) than what we have we'd be idiots not to take it,
> right? 

Obviously.  But the contentious cases often aren't the ones where that's
the case.

> The question is "What processes do we need to put in place to make a
> project of this size and dynamisticity work?"  I put forward a few of
> them.  I suggest we start somewhere (including airing gripes people have
> with the current system) and write down (i.e. build a web page, use
> TWiki)  what we're going to do about it. 
> I hate to make this analogy but we need a constitution or something like
> it.  Not so grandiose of course, but a written set of rules and are easy
> to interpret that can take care of the 80% case.  The 20% we'll always
> get to argue over but I'd rather not argue over the 100%. 

I think we're in the same boat here.  You believe that process can help
streamline the development process, and be used to help avoid the
disagreements we've run into recently (assuming I read you correctly :-).
I think so too.  I agree we can't bring too much process--that won't work
for a large number of reasons.  But a little bit of process can go a long
way.  In particular, I'm looking for a little bit of process that will
help address the perceived problems of the current situation.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to