Message-Id: <3.0.3.32.19980109151205.007b6100@localhost>
Date: Fri, 09 Jan 1998 15:12:05 -0800
To: new-httpd@apache.org
From: Brian Behlendorf <brian@organic.com>
Subject: Re: Change
In-Reply-To: <Pine.LNX.3.95dg3.980108214255.21175s-100000@twinlark.arcti
 c.org>
References: <3.0.3.32.19980108190107.00903490@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

At 09:59 PM 1/8/98 -0800, Dean Gaudet wrote:
>> 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. 

I don't mind if occasionally a fix breaks something on NT or another
platform.  So long as those doing commits make reasonable efforts to make
sure that doesn't happen, or flag it in big bold letters (HEY WIN32 FOLKS
YOU NEED TO HELP WITH THIS) that's fine.  

The simple fact is that it won't be easy for us to review changes made to
the code if it doesn't even compile.  If your projects doesn't compile,
don't commit it.  I think you're saying the same thing.  So maybe changing
#1 to "If your project doesn't compile, don't commit it" makes sense?

>> 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? 

No.  Something which adds new directives, takes existing directives into
new territory, or changes semantics (like vhost code).  If from the outside
util.c's routines don't change, go for it.  For something like ap_cpystrn,
I'd add that first + change a few strncpy's to use it, and over time shift
all the other strncpy's.

>> 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
>commit". 

More than that though; if the code has buffer overruns or security holes,
it's the same as though the one doing the commit wrote code with similar
problems.  Or if it doesn't use the API well, etc.  

>> 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. 

good point.  I think "code that doesn't do anything but just sits there and
thus #ifdef 0" is what I'd call half-baked.  Or, code that is half-way to
something really cool but significantly impacts the
performance/functionality of another stable piece".  

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects				  brian@organic.com