httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: cvs commit: apachen STATUS
Date Thu, 08 Jan 1998 20:15:23 GMT
No way!  This is even worse than what we do now.  Consider the following:

    1. patch code
    2. test patch until satisfied
    3. cvs diff -u >neato.patch
    4. review neato.patch, possibly edit out things you don't mean to commit
    5. copy patch to where I do all my non-work mail
    6. post patch with description to new-httpd
    7. wait for patch to appear, get Message-ID
    8. edit apachen/STATUS, commit STATUS
    9. wait for enough votes
    10. cvs update
    11. if I'm certain I haven't editted that code again since making the
	patch goto 14
	(this test almost always fails and I almost always have to go to 12)
    12.     cvs diff -u >neato2.patch
    13.     review neato2.patch make sure it's really what I want to commit still
    14. vi apachen/STATUS apachen/src/CHANGES
    15. cvs commit STATUS src/CHANGES src/foo/bar.c

And here's the steps a reviewer has to minimally perform:

    1. read post on new-httpd
    2. copy patch wherever you do your testing
    3. patch code, rebuild
    4. test
    5. post vote or edit/commit STATUS

And here are the steps that would need to be added for your proposed addition:

    7a. copy patch back from twinlark to apachen/WaitingVotes/neato.patch
    7b. cvs add neato.patch
    7c. cvs commit neato.patch

    15a. rm apachen/WaitingVotes/neato.patch
    15b. cvs !!

Contrast with:

    1. patch code
    2. test patch until satisfied
    3. cvs diff -u >neato.patch
    4. review neato.patch, possibly edit out things you don't mean to commit
    5. cvs commit src/CHANGES src/foo/bar.c
    6. goto 1 because you've still got way more time to play today

and for the minimal reviewer:

    1. read about patch on apache-cvs
    2. cvs update, rebuild
    3. test
    4. goto 1 because you've still got more time to play today

I suggest that you build a procmail filter that carbons messages
beginning with [PATCH] into another mailbox.  Or alternately grab or whatever mail archive is current and
search for the Message-ID... that's the whole reason I put the message ids
into the status ages ago.  And Randy I think was the person who asked for
the [PATCH] token in the subject so that he could filter it differently.

I now keep a carbon of every single message I receive in personal archive
folders so I can always look there.  But before I did that I used my
local mirror of


On Thu, 8 Jan 1998, Jim Jagielski wrote:

> wrote:
> > 
> >   Modified:    .        STATUS
> >   Log:
> >   recind Doug's -MApache::httpd_conf
> >   add  Doug's [PATCH] add -c and -C switches
> >   
> >   +    * Doug's [PATCH] add -c and -C switches
> >   +	<>
> >   +	Doug, Randy and Jim were +1 on original -MApache::httpd_conf
> >   +	patch, which was recinded in favor of this patch prompted by
> >   +	ideas from Ben and Dean.  Marc, Ken and Jim were also in favor
> >   +	of this over -M
> >   +	Status: Doug +1, Martin +1
> >    
> Doug,
> could you report this patch? I must have missed it.
> Oh yeah, who was it who suggested maybe adding patches to
> a subdirectory of the CVS tree? That's a good idea IMO... All
> we need is some-kind of naming for each patch, but it would
> make it a helluvalot easier to keep track of them. Not only
> that, but since they'll be under CVS, changes due to suggestions
> would be easy as well.
> Maybe something like ./Inprogress or something like that? Sure
> ./Patches makes sense but it could be confusing, esp to those who
> pull the CVS tree off and then say "Cool... some patches! I'll
> apply 'em!" :)
> -- 
> ====================================================================
>       Jim Jagielski            |       jaguNET Access Services
>           |
>             "Look at me! I'm wearing a cardboard belt!"

View raw message