Subject: Re: open source process issue
From: Christian Robottom Reis <kiko@async.com.br>
Date: Sun, 7 Oct 2001 18:12:05 -0300 (BRT)

On Sun, 7 Oct 2001, Jonathan S. Shapiro wrote:

> I think it's worth noting that the review level that's appropriate depends
> on what you are trying to achieve. For the EROS project, we are
> exceptionally concerned about assuring the code when we are done. Any
> significant change to the core system -- even one by me -- is discussed on
> the mailing list first. I have learned from several exceptions that this is
> a good idea, because I've had to back a lot of things out that turned out
> not to work for some perfectly straightforward reason.

I agree completely with both points. My further opinions are:

a) Any process will make hacking slower. This is a fact of life and we
   have to learn to minimize the impact as we can, but accept it
   ultimately.

b) Without a process, sooner or later your software will either fall
   apart, become something it wasn't meant to be, or die out. People like
   to hack on stuff, I agree, but when the "stuff" lacks a driving
   direction, they loose interest. I've seen this on many projects.

So I think that a bit more process will help us out a lot. The users will
be grateful; notice how it is now impossible to know what goes into each
Linux kernel release simply because the number of changes are too many,
and there is no standard bug control or version system used. And that, I
argue, is a bad thing.

> My thought, perhaps relevant to your discussion, is that a high-assurance
> result really does need a group that makes the decisions about what will be
> accepted into the code base. We will never simply accept patches without
> close review. I have no problem if people want to start a divergent effort,
> but for our project the need for robustness outweighs the need for urgent
> acceptance. For some users this won't be the right optimization.

Because at the beginning of a small software project, it's not what
counts. On any successful project, however, it is bound to be important
sooner than later.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL