Message-ID: <34C3D743.8BBE554D@Golux.Com>
Date: Mon, 19 Jan 1998 17:44:19 -0500
From: Rodent of Unusual Size <Ken.Coar@Golux.Com>
Organization: The Apache Group
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: [POLL] experiment with commit-then-review
References: <Pine.LNX.3.95dg3.980119103001.12441B-100000@twinlark.arctic.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Dean Gaudet wrote:
> 
> If I'm working on a bug report and fix the bug then I'm committing the fix
> right away.  I'm referring to things like that recent "basic auth doesn't
> use case insensitive comparisons".  I'm not about to post "oh I'm going to
> fix this bug" and then fix it... that's a waste.  CVS merges just fine.
> 
> But if I'm working on something more radical, like a util.c rewrite, then
> I will be posting.

The above certainly jibes with my understanding of what we're trying
to set up.  The "let people know" I have been taking to mean significant
work such as your vhost rewrite or my .h #ifdef wrapping.

> > >     * The CVS tree should be expected to compile at all times;
> > >       if it is possible that the code will result in some platforms
> > >       not compiling, notice of this should be announced.
> 
> ... notice of this can be announced in the CVS commit message, especially
> when it's a trivial change (such as an added .c file).

Works for me.

> > >     * Related changes should be posted at once, or very closely
> > >       together; no half-baked projects in the code.
> 
> Definition of "half-baked" please.  Tell me if my "-p" command line switch
> that comes with listenwrap is half-baked; tell me if my mod_allowdev
> module with Dirk's changes to give it run-time config commands is
> half-baked.

Now you're being silly.  It seems obvious to me that the sentence means
commit all related changes in a lump, or at least at the same time, and
not half to-day and half next week.  If you're doing something big like
rewriting the command loop, or changing a data structure, you
commit all the changes to all the relevant files at once.

> > >     * Any changes:
> > >          + which affect semantics of arguments to directives
> > >          + which would have to be implemented differently on other
> > >            architectures
> 
> If I want to write code that works on some unixes and provides backwards
> compatibility for other architectures I don't see what is wrong.  I've
> done this in the past, and I test with and without the new feature.
> Consider OPTIMIZE_TIMEOUTS, and the half-dozen serialization directives.

On the other hand, if you add something that works *only* on UNIX it's
only fair to give the Win32 folx warning - and if it cannot be done
under Win32 I think it's reasonable that they be able to veto the
change.  We decided long ago to maintain feature (if not bug) compatibility
across platforms.

You've got CVS access; Roy invited everyone to comment and make
changes.  You want fine-tuning to these guidelines?  Go ahead and
do it.  But let's get on with it and downsize the endless go-nowhere
discussions..

#ken	P-)}