httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [POLL] experiment with commit-then-review
Date Mon, 19 Jan 1998 18:36:09 GMT
On Sun, 18 Jan 1998, Rodent of Unusual Size wrote:

> Okey, this issue has been pretty quiet for a few days.
> Is anyone unhappy with the conditions for c-t-r as specified
> in <http://dev.apache.org/guidelines.html#ctr>?  (Reproduced
> below.)  If no-one has any heartburn with this, can we please
> say it's a go and get on with it?
> 
> Here's the section from the latest guidelines:
> 
> >   We are exploring a new process to help speed development,
> >   "commit-then-review". With a commit-then-review process, we
> >   trust that committers have a high degree of confidence in their
> >   committed patches --- higher than the typical [PATCH] post to the
> >   mailing list.
> >     * Advance notice (e.g., "I'll be working on flurgl.c") will
> >       be given

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. 

This distinction should be made.  Grey areas and all. 

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

> >     * Experimental new features must be discussed before implemented
> >     * The committer is responsible for the quality of the third-party
> >       code they bring into the code.

This and the first point cover the same areas. 

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

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

Dean



Mime
View raw message