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 15:46:48 GMT
On Thu, 8 Jan 1998, Jim Jagielski wrote:
>
> 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!" :)

I rather like this idea.  It's a major pain for me to extract
patches from mail in order to apply them.  Keeping STATUS in CVS
has worked out much better than I thought it would, so I'm +1
on trying this.

How about ./BeingVoted? <g>  Personally, I'd like to keep the 
name short - how about ./wip (work in process)?

Marc Slemko wrote:
> 
> This creates even more of a pain for people trying to do things, and
> _really_ clutters the commit logs.

The first part sounds like a personal opinion, and I don't see it.
I think doing this makes a lot of sense; it means that patches would
be submitted by putting them into CVS, and everyone automatically
gets them when they update their local repository.  It means that
the commit message describes the patch and thereby saves having to
send it as a separate message.  It means that multiple people can
work on any particular patch much more easily.  It means that the
new-httpd archive won't be quite as massive, since proposed code
changes will be in the apachen-cvs archive instead.  And it means
updating STATUS will be easier, since you don't have to send the
patch, go looking for the message ID, and then update STATUS; patch
file names are much simpler.

As for seeing two commit messages, once when the patch is submitted and
once when it's committed (or more, as it's tweaked) - I don't see it.
In terms of sheer volume of mail there should actually be about the
same.  And doing this makes it easy to filter - instead of looking
for "[PATCH]" look for the directory name.

> I'm not really sure it is necessary.

Necessary, schmecessary.  There are lots of things that aren't
necessary but we do 'em anyway.  Sometimes because they're Good
Things, sometimes for other reasons.  I don't think "it may not
be necessary" is anything like a good enough reason to not even
try it.

I'm +1 on this - but let's come up with a good name for the directory
first.. oh, and patchfile naming semantics, too.

#ken	P-)}



Mime
View raw message