httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: Change
Date Fri, 09 Jan 1998 03:06:49 GMT


On Thu, 8 Jan 1998, 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.

Dean thinks this sucks because it was presented as an additional duty to
perform while patching the code as opposed to replacing the duty of
posting the patch to new-httpd.  If the proposal is really to replace the
posting of the patch then say so, and get rid of apache-cvs and direct all
cvs commits to new-httpd.  It seems foolish for folks to subscribe to both
lists, and if they don't subscribe to apache-cvs they may wonder what's
going on.  It's not like apache-cvs is high volume. 

Aren't all freebsd commits sent to the main discussion lists?

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

... and makes things easier for other developers.  It's far less work than
the current or the example 1 or my modified example 1.

Patching code by hand is a manual process subject to failures (due to
conflicting patches).  This was one of the motivating factors for moving
to CVS ages ago.

"cvs update" on the other hand is subject only to failures when you've
made your own local modifications, in which case that's your own trouble
and you understand that by typing "cvs update".  But it's pretty damn easy
to test the latest server by typing 

    cvs update
    cd src
    ./Configure
    make clean
    make

Contrast with (and this is pretty much true of both the current system
and example 1):

    cvs update
    for i in patches/*; do
	oh have I applied this yet?  I'm not sure
	patch <$i
	some possibilities:
	    1. aw shit yeah I have
		oh damn which *.orig files do I have to rename?
	    
	    2. aw shit it doesn't merge
		oh damn the *.rej files don't make sense
		how do I back out of this one?
	    
	    3. oh wow it patched
    done
    cd src
    ./Configure
    make clean
    make
    oh damn one of those patches conflicted with another one and the
	server won't even compile now (IMNSHO higher probability than in
	the commit-then-review scenario)

I dunno.  There seems to be a lot more room for error and frustration
with the current system -- both leading to apathy.

Dean


Mime
View raw message