Date: Thu, 8 Jan 1998 14:02:35 -0700 (MST)
From: Marc Slemko <marcs@worldgate.com>
To: new-httpd@apache.org
Subject: Re: cvs commit: apachen STATUS
In-Reply-To: <34B4F4E8.39DF356D@Golux.Com>
Message-ID: <Pine.BSF.3.95q.980108135651.27965G-100000@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

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

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

You just finished telling Dean that the way he does things is irrelevant
because not everyone does it that way, now you are saying you want this
because it is hard for you to deal with patches in mail.

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

It is a fact that it creates more steps to try to make a patch work.

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

Right now the apache-cvs archive is useful for looking back trying to find
changes because there isn't much clutter.

When you start changing it so that every time anyone makes any little
change to their patch it fills up the apache-cvs archive (and, perhaps
more importantly, the commitlog) with junk it becomes very difficult to
use CVS effectively.

You are saying that you prefer two mailing lists with clutter to one
without clutter and one with clutter?  I don't.  You may not use
apache-cvs archives, I do.

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

But it puts it in the wrong place.  New suggestions, patches, discussion
doesn't belong on the apache-cvs list.  It belongs on new-httpd.  You can
not cleanly split it out, so trying to do so just creates more confusion.

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

Ok, let me put it this way: I hate the idea and find it completely
unnecessary and can not see what it improves on.  It is fine if all you do
are large patches once in a while.  For lots of small patches it
completely sucks.