httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: cvs commit: apachen STATUS
Date Thu, 08 Jan 1998 20:51:32 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
> 
> 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 !!

Wrong-o.  Steps 5, 6, 7, and 8 turn into a "cvs add" and 
"cvs commit STATUS src/WaitingVotes/neato.patch".  Half of that is your
7b.  Since you're not sending mail but letting the CVS commit do it for
you, the back-and-forth to twinlark is unnecessary.  The reviewer's
steps reduce by one also.

I don't think it's fair for you to introduce the twinlark business into
the discussion, since that's particular to you personally.  Or shall I
drag out the steps *I* have to follow because my mail isn't on UNIX?  I
thought not; that's peculiar to *my* environment and I wouldn't care
to enumerate them nor assume they apply to anyone else.

*I* like Jim's proposal in part because it gets rid of *my* back-and-forth
shenanigans due to my mail environment.

> 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

This has been beaten to death, IMHO.  What you propose here is fine for
development cycles, but not beta cycles - which is where we are now.
I thought the lazy voting system this past summer worked quite well.
Do you disagree?  I think the reason voting is getting in the way
right now is because we're allow creeping featurism.  The various
code reviews and features that are getting voted on right now have
no business occurring during the beta cycle.

SO maybe Ben is right, and we should plan on a 1.4, and *really*
feature-freeze 1.3 (since it obviously isn't frozen now if we're
voting on things like Doug's brilliant -c/-C feature).

{Sigh}

Everyone has to make sacrifices.  I think your analysis above is
worse that it would actually be.  Maybe we need to vote on the
./InProcess issue. <g>  I'm +1, at least for trying it.  If it
doesn't work, we can revert.  If it does, great.  Either way,
we're not sticking in the mud.

I don't see why you can't keep doing things the current way while
others try out the alternative Jim proposed.  If it gets down to
people entreating you to follow that model, I expect you'll bend
to it because it will have been shown to make things easier for
the majority.  Likewise, if no-one (or only a vocal minority) likes
the patch-directory-in-CVS business, we can do away with that.

#ken	P-)}

Mime
View raw message