httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: cvs commit: apachen STATUS
Date Thu, 08 Jan 1998 21:11:10 GMT


On Thu, 8 Jan 1998, Rodent of Unusual Size wrote:

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

Yeah what about all the other folks who don't read apache-cvs?

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

Give me a fucking break.  That's how I have to do development.  I don't
use my work email for non-work things.  I use a machine at my house to do
a lot of apache development.  I don't send mail from that machine.  I have
to do the copying. 

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

"I don't think it's fair for you to introduce your personal mail problems
into this discussion."

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