httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Change
Date Fri, 09 Jan 1998 03:01:07 GMT
At 09:25 PM 1/8/98 -0500, Jim Jagielski wrote:
>Change is good.
>Example 1: The current process of posting patches and then having
>M-ID in status. A nice change IMO would be to place the patches
>somewhere under the CVS tree to allow easy and consistant access
>to the patches. Change-type: Evolutionary. As far as I can recall,
>Dean thought this sucked, even though it helped some people out.

And Marc, and (for the record now) me.  I guess everyone stopped reading my
last message before I proposed another alternative, which was to have
patches auto-culled from new-httpd mailings into something like so that we would have easy and consistant
access to them.  

>Example 2: The current review-and-commit process, which has been
>used since Day 1 is slow. A nice change would be to instead
>have commit-and-review. Change-type: Revolutionary. Dean liked it
>cause it made things easier for him.

It'll make things easier for all developers.

>Dean, this has me confused :) :)
>Seriously, we all like change that help us out, and dislike change
>that either doesn't help us or makes things tougher.
>I think we all are compromising, common sense people. We can
>make things better. But sometimes evolution is "easier" than
>revolution, and given time can do more.

I don't know if you really want to go on a philosophy bent here, but I'll
dispute the notion that evolution is obviously a better option than

Someone did mention "trust", and for me it really is an issue of trust as
well.  With a commit-then-review, we "trust" that committers have a high
degree of confidence in their committed patches - perhaps even higher than
the typical [PATCH] post to new-httpd.  Perhaps we could come up with a
standard we expect those with commit access to hold up to.  Let me take a
hash at this:

1) The CVS tree should be expected to compile at all times
2) Experimental new features must be discussed before implemented
3) The committer is responsible for the quality of the third-party code
   they bring into the code.
4) Related changes should be posted at once, or very closely together;
   no half-baked projects in the code.

Any changes:

...which affect symantics of arguments to directives 
...which would have to be implemented differently on other architectures
...which significantly add to the runtime size of the program

need to be discussed on new-httpd before it gets committed, even

Thoughts?  Too conservative?  Too loose?  A bad idea altogether?


specialization is for insects

View raw message