You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 1998/01/08 14:30:56 UTC
Re: cvs commit: apachen STATUS
dougm@hyperreal.org wrote:
>
> Modified: . STATUS
> Log:
> recind Doug's -MApache::httpd_conf
> add Doug's [PATCH] add -c and -C switches
>
> + * Doug's [PATCH] add -c and -C switches
> + <34...@telebusiness.co.nz>
> + Doug, Randy and Jim were +1 on original -MApache::httpd_conf
> + patch, which was recinded in favor of this patch prompted by
> + ideas from Ben and Dean. Marc, Ken and Jim were also in favor
> + of this over -M
> + Status: Doug +1, Martin +1
>
Doug,
could you report this patch? I must have missed it.
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!" :)
--
====================================================================
Jim Jagielski | jaguNET Access Services
jim@jaguNET.com | http://www.jaguNET.com/
"Look at me! I'm wearing a cardboard belt!"
Re: cvs commit: apachen STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Doug MacEachern wrote:
>
> - fprintf(stderr, "Usage: %s [-d directory] [-f file] [-v] [-h] [-l]\n", bin);
> + fprintf(stderr, "Usage: %s [-d directory] [-f file] [-C|-c command] [-v] [-h] [-l]\n", bin);
Erm, I find "[-C|-c command]" ambiguous. It looks like you can only use one
of "-C" or "-c command" on the command line. I would prefer something more
like "[-C \"directive\"] [-c \"directive\"]". I have no real opinion about
whether the quotes should be included or not (\"directive\" or just
directive).
Actually, considering the multiplatform issues, I'd prefer to make them overt
rather than assuming the user knows to quote parameters that contain spaces
or other special characters.
> + fprintf(stderr, "-C command : process command before reading config files\n");
> + fprintf(stderr, "-c command : process command after reading config files\n");
And as someone else mentioned, I think this should be "directive" rather than
command; the latter sounds like you can use a shell command here.
What happens if you use something like:
# httpd -C "<VirtualHost foo>" -c "</VirtualHost>" -d /apache
? <g>
#ken P-)}
Re: cvs commit: apachen STATUS
Posted by Doug MacEachern <do...@telebusiness.co.nz>.
Jim Jagielski wrote:
> dougm@hyperreal.org wrote:
> >
> > Modified: . STATUS
> > Log:
> > recind Doug's -MApache::httpd_conf
> > add Doug's [PATCH] add -c and -C switches
> >
> > + * Doug's [PATCH] add -c and -C switches
> > + <34...@telebusiness.co.nz>
> > + Doug, Randy and Jim were +1 on original -MApache::httpd_conf
> > + patch, which was recinded in favor of this patch prompted by
> > + ideas from Ben and Dean. Marc, Ken and Jim were also in favor
> > + of this over -M
> > + Status: Doug +1, Martin +1
> >
>
> Doug,
>
> could you report this patch? I must have missed it.
sure, here it is.
-Doug
Re: cvs commit: apachen STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Martin Kraemer wrote:
>
> On Thu, Jan 08, 1998 at 12:15:23PM -0800, Dean Gaudet wrote:
> >
> > 3. cvs diff -u >neato.patch
> ------------------^^
> Yeah! Perhaps it's time to change the recommendation to use -C context diffs
> (found in some of the dev.apache.org documents) to use -u unified diffs
> instead.
Where've you been, Martin? That war was months ago, and the Unified Differs
won! <g> -u is supposed to be the default now.
Kinda nice to find out Your Side won when you didn't even know the
war was over, eh? <g>
#ken P-)}
Re: cvs commit: apachen STATUS
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Thu, Jan 08, 1998 at 12:15:23PM -0800, Dean Gaudet wrote:
>
> 3. cvs diff -u >neato.patch
------------------^^
Yeah! Perhaps it's time to change the recommendation to use -C context diffs
(found in some of the dev.apache.org documents) to use -u unified diffs
instead.
Okay, okay, calm down everybody. I know there have been civil wars about
this topic. I just thought perhaps common practice has changed the tastes...
Just my $.02, again.
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: cvs commit: apachen STATUS
Posted by Dean Gaudet <dg...@arctic.org>.
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-)}
>
Re: cvs commit: apachen STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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-)}
Re: cvs commit: apachen STATUS
Posted by ra...@bellglobal.com.
> 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 is how the PHP3 development cycle works. There are 6 core developers
and about 10 other regular contributors. Everyone has commit priviledges.
We occasionally need to back out an ill-advised commit, but 99% of the time
the commits are either fine or a little bit of tweaking by one of the core
guys makes it fine. The only thing we have any semblance of voting on is
high-level concepts. And it isn't really a vote, just some heated
discussion back and forth until mutual agreement is reached.
And yes, the HEAD CVS doesn't always work very well. Sometimes it doesn't
even compile. But that also means that when there is a problem in a
patch, it is discovered right away while the originator is still around and
has the code fresh in his mind. I have found that with the Apache cycle,
because it takes so long for a change to go through, it is difficult to
debug resulting problems.
I am not saying that this is necessarily the way to go for Apache, but I
do agree with Dean. The current setup sucks. I for one would be testing
a heck of a lot more patches if I could just cvs update and recompile. I
don't have the cycles in my day to manually patch things. That's
obviously how we are finding most of the problems right now anyway. Lots of
patches that get +1'ed end up causing things to break anyway and this is
caught months later instead of right away because of the current setup.
-Rasmus
Re: cvs commit: apachen STATUS
Posted by Dean Gaudet <dg...@arctic.org>.
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 !!
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 suggest that you build a procmail filter that carbons messages
beginning with [PATCH] into another mailbox. Or alternately grab
dev.apache.org:/httpd/mail/nh.9801 or whatever mail archive is current and
search for the Message-ID... that's the whole reason I put the message ids
into the status ages ago. And Randy I think was the person who asked for
the [PATCH] token in the subject so that he could filter it differently.
I now keep a carbon of every single message I receive in personal archive
folders so I can always look there. But before I did that I used my
local mirror of dev.apache.org/httpd.
Dean
On Thu, 8 Jan 1998, Jim Jagielski wrote:
> dougm@hyperreal.org wrote:
> >
> > Modified: . STATUS
> > Log:
> > recind Doug's -MApache::httpd_conf
> > add Doug's [PATCH] add -c and -C switches
> >
> > + * Doug's [PATCH] add -c and -C switches
> > + <34...@telebusiness.co.nz>
> > + Doug, Randy and Jim were +1 on original -MApache::httpd_conf
> > + patch, which was recinded in favor of this patch prompted by
> > + ideas from Ben and Dean. Marc, Ken and Jim were also in favor
> > + of this over -M
> > + Status: Doug +1, Martin +1
> >
>
> Doug,
>
> could you report this patch? I must have missed it.
>
> 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!" :)
>
> --
> ====================================================================
> Jim Jagielski | jaguNET Access Services
> jim@jaguNET.com | http://www.jaguNET.com/
> "Look at me! I'm wearing a cardboard belt!"
>
Re: cvs commit: apachen STATUS
Posted by Marc Slemko <ma...@worldgate.com>.
Oh, if you really want to do this consider putting it in a different
module and have it sent to a different list, etc.
Re: cvs commit: apachen STATUS
Posted by Marc Slemko <ma...@worldgate.com>.
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.
Re: cvs commit: apachen STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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-)}
Re: cvs commit: apachen STATUS
Posted by Marc Slemko <ma...@worldgate.com>.
This creates even more of a pain for people trying to do things, and
_really_ clutters the commit logs.
I'm not really sure it is necessary.
On Thu, 8 Jan 1998, Jim Jagielski wrote:
> dougm@hyperreal.org wrote:
> >
> > Modified: . STATUS
> > Log:
> > recind Doug's -MApache::httpd_conf
> > add Doug's [PATCH] add -c and -C switches
> >
> > + * Doug's [PATCH] add -c and -C switches
> > + <34...@telebusiness.co.nz>
> > + Doug, Randy and Jim were +1 on original -MApache::httpd_conf
> > + patch, which was recinded in favor of this patch prompted by
> > + ideas from Ben and Dean. Marc, Ken and Jim were also in favor
> > + of this over -M
> > + Status: Doug +1, Martin +1
> >
>
> Doug,
>
> could you report this patch? I must have missed it.
>
> 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!" :)
>
> --
> ====================================================================
> Jim Jagielski | jaguNET Access Services
> jim@jaguNET.com | http://www.jaguNET.com/
> "Look at me! I'm wearing a cardboard belt!"
>