httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: cvs commit: apachen STATUS
Date Thu, 08 Jan 1998 20:50:15 GMT
Dean Gaudet wrote:
> 
> 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 twinlark.arctic.org 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

With a ./patches dir, there is no need for #6 or #7

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

#2 not needed with ./patches

>     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

Why substeps? Just to make look like more stuff? You add neato.patch
to ./patches, then while updating STATUS which you have to do
anyway you add the 'cvs add' and commit ... STATUS 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'm assuming these last 2 sections are the "We all commit whatever
the flark we want to and hope and pray that people keep up
to date."

yeah... sure... pull the other one.

I can understand wanting to play around with code, but I think that
if one has the priv to CVS commit, the have a responsibility to
make sure that others are aware of what you're doing. I don't consider
Apache some meld of all of our seperate sandboxes, but all of us in
one sandbox.

What sort of group or team actually works by letting all the members do
whatever the flark they want?
-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
            "Look at me! I'm wearing a cardboard belt!"

Mime
View raw message