httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Change
Date Fri, 09 Jan 1998 05:59:21 GMT

On Thu, 8 Jan 1998, Brian Behlendorf wrote:

> 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

Not feasible.  This isn't how development trees work.  Even now I break
compilation on NT frequently and Paul or Ben fix it up as soon as they
can.  Even if I cared to learn an NT development environment I doubt I'd
test on it frequently... since I'm so hooked into doing my development
from wherever I can get a terminal session.  I hate GUI crap. 

Committers should be expected to make their stuff compile on their own box
before committing of course.  That follows from the fact that they have to
test first too. 

> 2) Experimental new features must be discussed before implemented

What's an "experimental new feature"?  Is ap_cpystrn() an experimental new
feature?  Is a rewritten util.c that gets rid of many inefficiencies an
experimental new feature? 

> 3) The committer is responsible for the quality of the third-party code
>    they bring into the code.

Definately, but follows from "the committer has tested the code they

> 4) Related changes should be posted at once, or very closely together;
>    no half-baked projects in the code.

You mean no *more* half-baked projects in the code?  :)

half-baked projects are quite useful in some cases.  For example, my
listenwrap patch could quite easily exist in the code right now without
breaking a thing or changing behaviour.  But it's not fully baked yet, it
still has to deal with moving certain functions out of the parent. 

The mod_allowdev module that Dirk/I did is half-baked, but wouldn't break
anything.  I won't consider it fully baked until it's able to handle
automounted user home directories, and I have an idea on how to do that...
but haven't done it yet:  a directive "AllowDevDynamic regex expansion",
if the regex matches the URL then the file served must have a device id
matching the device id of the expansion.  This works quite nicely for
autohome systems because each user's home directory has its own device
number.  Then say bye-bye to the symlink code brokenness -- it requires
only one extra stat() call per requests as opposed to the symlink stuff
which has to lstat() until the cows come home and is far harder to
configure correctly. 

In the linux kernel "half-baked" things are available when you select the
"experimental drivers and options" option.  Useful stuff like framerelay,
RST cookies, transparent proxying and multicast routing are experimental
and work well enough... but just aren't finished. 


View raw message