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/09 03:25:51 UTC
Change
Change is good.
Example 1: The current process of posting patches and then having
M-ID in status. A nice change IMO would be to place the patches
somewhere under the CVS tree to allow easy and consistant access
to the patches. Change-type: Evolutionary. As far as I can recall,
Dean thought this sucked, even though it helped some people out.
Example 2: The current review-and-commit process, which has been
used since Day 1 is slow. A nice change would be to instead
have commit-and-review. Change-type: Revolutionary. Dean liked it
cause it made things easier for him.
Dean, this has me confused :) :)
Seriously, we all like change that help us out, and dislike change
that either doesn't help us or makes things tougher.
I think we all are compromising, common sense people. We can
make things better. But sometimes evolution is "easier" than
revolution, and given time can do more.
--
====================================================================
Jim Jagielski | jaguNET Access Services
jim@jaguNET.com | http://www.jaguNET.com/
"Look at me! I'm wearing a cardboard belt!"
Re: Change
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 9 Jan 1998, Rodent of Unusual Size wrote:
> Randy Terbush wrote:
> >
> > :-) Had not gotten around to a response. If others feel this would
> > be helpful, and someone can find time to do it, that would be great.
> > CVS is not the answer to everything. I personally prefer to filter
> > patches into my mail reader. Makes it nice to follow the discussion
> > surrounding a particular patch as well. I'd be happy to help anyone
> > with procmail if they want to do the same.
>
> I have several automagic things running already (the STATUS messages, the
> manual-index.cgi index generation, a couple of others). I'd like to
> take a whack at auto-culling "Subject: [PATCH]" messages into an
> apachen/inprocess directory and committing them. Unless someone else
> wants to do it. Hmmm.. how to differentiate patches against 1.3 from
> those against 1.2 - or other versions in the future?
>
> Assuming that there's general agreement for the effort.
Use a seperate repository.
Then those of us who don't care for such things don't have to take special
effort to always avoid wasting time updating it. Then it can be handled
seperately. Then it doesn't screw things up.
An ideal system would be able to keep threads of discussion on the message
in a file associated with the patch.
Re: Change
Posted by Marc Slemko <ma...@worldgate.com>.
Why do they have to have any revision control anyway? Make a script, have
it put them on a web and/or ftp server then it should be easy enough for
most platforms to set something up to automatically have them mirrored
over to your box if that is what you desire, or you can access them one by
one, etc.
Multiple people editing patches seldom works right anyway because updates
are a royal pain...
On Thu, 8 Jan 1998, Dean Gaudet wrote:
> It could be interesting if someone decides to spoof mail as a [PATCH]...
> I certainly don't want my "cvs update" to suddenly take a few hours
> because a zillion messages were accepted. I think I'm with Marc -- put
> this under a separate hierarchy. I certainly don't need it, I have no
> problem getting patches from my mail onto my testing machine (other than
> the waste of time it is applying them by hand).
>
> Yes I know we already have the bugdb email interface. But this feels
> different as far as security impact goes.
>
> Dean
>
> On Fri, 9 Jan 1998, Rodent of Unusual Size wrote:
>
> > Randy Terbush wrote:
> > >
> > > :-) Had not gotten around to a response. If others feel this would
> > > be helpful, and someone can find time to do it, that would be great.
> > > CVS is not the answer to everything. I personally prefer to filter
> > > patches into my mail reader. Makes it nice to follow the discussion
> > > surrounding a particular patch as well. I'd be happy to help anyone
> > > with procmail if they want to do the same.
> >
> > I have several automagic things running already (the STATUS messages, the
> > manual-index.cgi index generation, a couple of others). I'd like to
> > take a whack at auto-culling "Subject: [PATCH]" messages into an
> > apachen/inprocess directory and committing them. Unless someone else
> > wants to do it. Hmmm.. how to differentiate patches against 1.3 from
> > those against 1.2 - or other versions in the future?
> >
> > Assuming that there's general agreement for the effort.
> >
> > #ken P-)}
> >
>
Re: Change
Posted by Dean Gaudet <dg...@arctic.org>.
It could be interesting if someone decides to spoof mail as a [PATCH]...
I certainly don't want my "cvs update" to suddenly take a few hours
because a zillion messages were accepted. I think I'm with Marc -- put
this under a separate hierarchy. I certainly don't need it, I have no
problem getting patches from my mail onto my testing machine (other than
the waste of time it is applying them by hand).
Yes I know we already have the bugdb email interface. But this feels
different as far as security impact goes.
Dean
On Fri, 9 Jan 1998, Rodent of Unusual Size wrote:
> Randy Terbush wrote:
> >
> > :-) Had not gotten around to a response. If others feel this would
> > be helpful, and someone can find time to do it, that would be great.
> > CVS is not the answer to everything. I personally prefer to filter
> > patches into my mail reader. Makes it nice to follow the discussion
> > surrounding a particular patch as well. I'd be happy to help anyone
> > with procmail if they want to do the same.
>
> I have several automagic things running already (the STATUS messages, the
> manual-index.cgi index generation, a couple of others). I'd like to
> take a whack at auto-culling "Subject: [PATCH]" messages into an
> apachen/inprocess directory and committing them. Unless someone else
> wants to do it. Hmmm.. how to differentiate patches against 1.3 from
> those against 1.2 - or other versions in the future?
>
> Assuming that there's general agreement for the effort.
>
> #ken P-)}
>
Re: Change
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Randy Terbush wrote:
>
> :-) Had not gotten around to a response. If others feel this would
> be helpful, and someone can find time to do it, that would be great.
> CVS is not the answer to everything. I personally prefer to filter
> patches into my mail reader. Makes it nice to follow the discussion
> surrounding a particular patch as well. I'd be happy to help anyone
> with procmail if they want to do the same.
I have several automagic things running already (the STATUS messages, the
manual-index.cgi index generation, a couple of others). I'd like to
take a whack at auto-culling "Subject: [PATCH]" messages into an
apachen/inprocess directory and committing them. Unless someone else
wants to do it. Hmmm.. how to differentiate patches against 1.3 from
those against 1.2 - or other versions in the future?
Assuming that there's general agreement for the effort.
#ken P-)}
Re: Change
Posted by Randy Terbush <ra...@covalent.net>.
On Thu, Jan 08, 1998 at 07:01:07PM -0800, Brian Behlendorf wrote:
> At 09:25 PM 1/8/98 -0500, Jim Jagielski wrote:
> >Change is good.
> >
> >Example 1: The current process of posting patches and then having
> >M-ID in status. A nice change IMO would be to place the patches
> >somewhere under the CVS tree to allow easy and consistant access
> >to the patches. Change-type: Evolutionary. As far as I can recall,
> >Dean thought this sucked, even though it helped some people out.
>
> And Marc, and (for the record now) me. I guess everyone stopped reading my
> last message before I proposed another alternative, which was to have
> patches auto-culled from new-httpd mailings into something like
> http://dev.apache.org/patches/ so that we would have easy and consistant
> access to them.
:-) Had not gotten around to a response. If others feel this would
be helpful, and someone can find time to do it, that would be great.
CVS is not the answer to everything. I personally prefer to filter
patches into my mail reader. Makes it nice to follow the discussion
surrounding a particular patch as well. I'd be happy to help anyone
with procmail if they want to do the same.
Re: Change
Posted by Randy Terbush <ra...@covalent.net>.
On Thu, Jan 08, 1998 at 07:06:49PM -0800, Dean Gaudet wrote:
>
>
> On Thu, 8 Jan 1998, Jim Jagielski wrote:
>
> > Change is good.
> >
> > Example 1: The current process of posting patches and then having
> > M-ID in status. A nice change IMO would be to place the patches
> > somewhere under the CVS tree to allow easy and consistant access
> > to the patches. Change-type: Evolutionary. As far as I can recall,
> > Dean thought this sucked, even though it helped some people out.
>
> Dean thinks this sucks because it was presented as an additional duty to
> perform while patching the code as opposed to replacing the duty of
> posting the patch to new-httpd. If the proposal is really to replace the
> posting of the patch then say so, and get rid of apache-cvs and direct all
> cvs commits to new-httpd. It seems foolish for folks to subscribe to both
> lists, and if they don't subscribe to apache-cvs they may wonder what's
> going on. It's not like apache-cvs is high volume.
>
> Aren't all freebsd commits sent to the main discussion lists?
No. And I would not want to clutter new-httpd with even more fluff
to filter out. The current setup is very easy to filter into it's
own archive.
Re: Change
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 9 Jan 1998, Brian Behlendorf wrote:
> The simple fact is that it won't be easy for us to review changes made to
> the code if it doesn't even compile. If your projects doesn't compile,
> don't commit it. I think you're saying the same thing. So maybe changing
> #1 to "If your project doesn't compile, don't commit it" makes sense?
+1, or changing it to "if your project hasn't been tested, then don't
commit it" which is more specific.
> >> 3) The committer is responsible for the quality of the third-party code
> >> they bring into the code.
> >
> >Definately, but follows from "the committer has tested the code they
> >commit".
>
> More than that though; if the code has buffer overruns or security holes,
> it's the same as though the one doing the commit wrote code with similar
> problems. Or if it doesn't use the API well, etc.
Right and it's easier for someone reviewing the commit to make a change to
improve this situation.
> good point. I think "code that doesn't do anything but just sits there and
> thus #ifdef 0" is what I'd call half-baked. Or, code that is half-way to
> something really cool but significantly impacts the
> performance/functionality of another stable piece".
Works for me.
Dean
Re: Change
Posted by Brian Behlendorf <br...@organic.com>.
At 09:59 PM 1/8/98 -0800, Dean Gaudet wrote:
>> 1) The CVS tree should be expected to compile at all times
>
>Not feasible. This isn't how development trees work. Even now I break
>compilation on NT frequently and Paul or Ben fix it up as soon as they
>can. Even if I cared to learn an NT development environment I doubt I'd
>test on it frequently... since I'm so hooked into doing my development
>from wherever I can get a terminal session. I hate GUI crap.
>
>Committers should be expected to make their stuff compile on their own box
>before committing of course. That follows from the fact that they have to
>test first too.
I don't mind if occasionally a fix breaks something on NT or another
platform. So long as those doing commits make reasonable efforts to make
sure that doesn't happen, or flag it in big bold letters (HEY WIN32 FOLKS
YOU NEED TO HELP WITH THIS) that's fine.
The simple fact is that it won't be easy for us to review changes made to
the code if it doesn't even compile. If your projects doesn't compile,
don't commit it. I think you're saying the same thing. So maybe changing
#1 to "If your project doesn't compile, don't commit it" makes sense?
>> 2) Experimental new features must be discussed before implemented
>
>What's an "experimental new feature"? Is ap_cpystrn() an experimental new
>feature? Is a rewritten util.c that gets rid of many inefficiencies an
>experimental new feature?
No. Something which adds new directives, takes existing directives into
new territory, or changes semantics (like vhost code). If from the outside
util.c's routines don't change, go for it. For something like ap_cpystrn,
I'd add that first + change a few strncpy's to use it, and over time shift
all the other strncpy's.
>> 3) The committer is responsible for the quality of the third-party code
>> they bring into the code.
>
>Definately, but follows from "the committer has tested the code they
>commit".
More than that though; if the code has buffer overruns or security holes,
it's the same as though the one doing the commit wrote code with similar
problems. Or if it doesn't use the API well, etc.
>> 4) Related changes should be posted at once, or very closely together;
>> no half-baked projects in the code.
>
>You mean no *more* half-baked projects in the code? :)
>
>half-baked projects are quite useful in some cases. For example, my
>listenwrap patch could quite easily exist in the code right now without
>breaking a thing or changing behaviour. But it's not fully baked yet, it
>still has to deal with moving certain functions out of the parent.
>
>The mod_allowdev module that Dirk/I did is half-baked, but wouldn't break
>anything. I won't consider it fully baked until it's able to handle
>automounted user home directories, and I have an idea on how to do that...
>but haven't done it yet: a directive "AllowDevDynamic regex expansion",
>if the regex matches the URL then the file served must have a device id
>matching the device id of the expansion. This works quite nicely for
>autohome systems because each user's home directory has its own device
>number. Then say bye-bye to the symlink code brokenness -- it requires
>only one extra stat() call per requests as opposed to the symlink stuff
>which has to lstat() until the cows come home and is far harder to
>configure correctly.
>
>In the linux kernel "half-baked" things are available when you select the
>"experimental drivers and options" option. Useful stuff like framerelay,
>RST cookies, transparent proxying and multicast routing are experimental
>and work well enough... but just aren't finished.
good point. I think "code that doesn't do anything but just sits there and
thus #ifdef 0" is what I'd call half-baked. Or, code that is half-way to
something really cool but significantly impacts the
performance/functionality of another stable piece".
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: Change
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 8 Jan 1998, Brian Behlendorf wrote:
> Someone did mention "trust", and for me it really is an issue of trust as
> well. With a commit-then-review, we "trust" that committers have a high
> degree of confidence in their committed patches - perhaps even higher than
> the typical [PATCH] post to new-httpd. Perhaps we could come up with a
> standard we expect those with commit access to hold up to. Let me take a
> hash at this:
>
> 1) The CVS tree should be expected to compile at all times
Not feasible. This isn't how development trees work. Even now I break
compilation on NT frequently and Paul or Ben fix it up as soon as they
can. Even if I cared to learn an NT development environment I doubt I'd
test on it frequently... since I'm so hooked into doing my development
from wherever I can get a terminal session. I hate GUI crap.
Committers should be expected to make their stuff compile on their own box
before committing of course. That follows from the fact that they have to
test first too.
> 2) Experimental new features must be discussed before implemented
What's an "experimental new feature"? Is ap_cpystrn() an experimental new
feature? Is a rewritten util.c that gets rid of many inefficiencies an
experimental new feature?
> 3) The committer is responsible for the quality of the third-party code
> they bring into the code.
Definately, but follows from "the committer has tested the code they
commit".
> 4) Related changes should be posted at once, or very closely together;
> no half-baked projects in the code.
You mean no *more* half-baked projects in the code? :)
half-baked projects are quite useful in some cases. For example, my
listenwrap patch could quite easily exist in the code right now without
breaking a thing or changing behaviour. But it's not fully baked yet, it
still has to deal with moving certain functions out of the parent.
The mod_allowdev module that Dirk/I did is half-baked, but wouldn't break
anything. I won't consider it fully baked until it's able to handle
automounted user home directories, and I have an idea on how to do that...
but haven't done it yet: a directive "AllowDevDynamic regex expansion",
if the regex matches the URL then the file served must have a device id
matching the device id of the expansion. This works quite nicely for
autohome systems because each user's home directory has its own device
number. Then say bye-bye to the symlink code brokenness -- it requires
only one extra stat() call per requests as opposed to the symlink stuff
which has to lstat() until the cows come home and is far harder to
configure correctly.
In the linux kernel "half-baked" things are available when you select the
"experimental drivers and options" option. Useful stuff like framerelay,
RST cookies, transparent proxying and multicast routing are experimental
and work well enough... but just aren't finished.
Dean
Re: Change
Posted by Brian Behlendorf <br...@organic.com>.
At 09:25 PM 1/8/98 -0500, Jim Jagielski wrote:
>Change is good.
>
>Example 1: The current process of posting patches and then having
>M-ID in status. A nice change IMO would be to place the patches
>somewhere under the CVS tree to allow easy and consistant access
>to the patches. Change-type: Evolutionary. As far as I can recall,
>Dean thought this sucked, even though it helped some people out.
And Marc, and (for the record now) me. I guess everyone stopped reading my
last message before I proposed another alternative, which was to have
patches auto-culled from new-httpd mailings into something like
http://dev.apache.org/patches/ so that we would have easy and consistant
access to them.
>Example 2: The current review-and-commit process, which has been
>used since Day 1 is slow. A nice change would be to instead
>have commit-and-review. Change-type: Revolutionary. Dean liked it
>cause it made things easier for him.
It'll make things easier for all developers.
>Dean, this has me confused :) :)
>
>Seriously, we all like change that help us out, and dislike change
>that either doesn't help us or makes things tougher.
>
>I think we all are compromising, common sense people. We can
>make things better. But sometimes evolution is "easier" than
>revolution, and given time can do more.
I don't know if you really want to go on a philosophy bent here, but I'll
dispute the notion that evolution is obviously a better option than
revolution.
Someone did mention "trust", and for me it really is an issue of trust as
well. With a commit-then-review, we "trust" that committers have a high
degree of confidence in their committed patches - perhaps even higher than
the typical [PATCH] post to new-httpd. Perhaps we could come up with a
standard we expect those with commit access to hold up to. Let me take a
hash at this:
1) The CVS tree should be expected to compile at all times
2) Experimental new features must be discussed before implemented
3) The committer is responsible for the quality of the third-party code
they bring into the code.
4) Related changes should be posted at once, or very closely together;
no half-baked projects in the code.
Any changes:
...which affect symantics of arguments to directives
...which would have to be implemented differently on other architectures
...which significantly add to the runtime size of the program
need to be discussed on new-httpd before it gets committed, even
experimentally.
Thoughts? Too conservative? Too loose? A bad idea altogether?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: Change
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 9 Jan 1998, Rob Hartill wrote:
> On Fri, 9 Jan 1998, Marc Slemko wrote:
>
> > That doesn't solve anything because it just creates yet another tree,
>
> doesn't it solve the problem of having to generate patches for people to
> review and doesn't it solve the problem of the hassle of applying those
> patches to complete the review ?
Sure.
>
> Some people want to commit then have their commits reviewed. Others want
> to have commits reviewed first. Both sides get what they want, no ?
Sure. But both sides also get the very bad hassle of trying to be sure
that effort on one tree isn't wasted because it doesn't get into the
other, etc.
The FreeBSD way doesn't really work this way; there, -current is like 1.3,
-stable like 1.2. In the past, -stable had very little work done on it
and quickly fell behind. Now they are trying doing more work on -stable
to keep it updated with some things. They, however, have a lot more
people doing it and generally no commits are made to -stable unless they
are in -current first. There are exceptions, of course, and some things
aren't need in -current, etc.
>
> > someone these trees have to magically stay together.
>
> perhaps the magic can be assigned to the release manager who keeps
> the stable tree in-sync with what has been reviewed and approved.
>
> The current cvs notification system generates the diffs that the RM
> can use to bring the stable tree up to date.
>
The problem is that either that happens right away, or it gets left around
until later and then so many other things have changed that it has to be
manually patched, etc.
I simply don't think we have the resources for that.
> I thought it solved various problems at the heart of the current
> debate.
>
> > It is a big enough
> > pain maintaining minor changes to two source trees right now...
> >
> > On Fri, 9 Jan 1998, Rob Hartill wrote:
> >
> > >
> > > don't shoot me, but what about a CVS tree for commit-then-review
> > > and one for review-then-commit ?
> > >
> > > i.e. if I have a change I want people to review, I drop it into
> > > the c-t-r, people review it (don't, complain or whatever) and then
> > > it can be moved into the r-t-c tree later. The r-t-c tree can then
> > > be viewed as "stable" and safe for semi-automatic tarballing for
> > > release at any time. Developers would mostly use the c-t-r code,
> > > new-httpd testers (and there are lots of them) would us the r-t-c
> > > code.
> > >
> > > This is similar to FreeBSD's -current and -stable except that they
> > > let those two drift miles apart. If we can keep the two close together
> > > (in content) then it could work.
> > >
> > > --
> > > Rob Hartill Internet Movie Database (Ltd)
> > > http://www.moviedatabase.com/ .. a site for sore eyes.
> > >
> >
> >
>
> --
> Rob Hartill Internet Movie Database (Ltd)
> http://www.moviedatabase.com/ .. a site for sore eyes.
>
Re: Change
Posted by Rob Hartill <ro...@imdb.com>.
On Fri, 9 Jan 1998, Marc Slemko wrote:
> That doesn't solve anything because it just creates yet another tree,
doesn't it solve the problem of having to generate patches for people to
review and doesn't it solve the problem of the hassle of applying those
patches to complete the review ?
Some people want to commit then have their commits reviewed. Others want
to have commits reviewed first. Both sides get what they want, no ?
> someone these trees have to magically stay together.
perhaps the magic can be assigned to the release manager who keeps
the stable tree in-sync with what has been reviewed and approved.
The current cvs notification system generates the diffs that the RM
can use to bring the stable tree up to date.
I thought it solved various problems at the heart of the current
debate.
> It is a big enough
> pain maintaining minor changes to two source trees right now...
>
> On Fri, 9 Jan 1998, Rob Hartill wrote:
>
> >
> > don't shoot me, but what about a CVS tree for commit-then-review
> > and one for review-then-commit ?
> >
> > i.e. if I have a change I want people to review, I drop it into
> > the c-t-r, people review it (don't, complain or whatever) and then
> > it can be moved into the r-t-c tree later. The r-t-c tree can then
> > be viewed as "stable" and safe for semi-automatic tarballing for
> > release at any time. Developers would mostly use the c-t-r code,
> > new-httpd testers (and there are lots of them) would us the r-t-c
> > code.
> >
> > This is similar to FreeBSD's -current and -stable except that they
> > let those two drift miles apart. If we can keep the two close together
> > (in content) then it could work.
> >
> > --
> > Rob Hartill Internet Movie Database (Ltd)
> > http://www.moviedatabase.com/ .. a site for sore eyes.
> >
>
>
--
Rob Hartill Internet Movie Database (Ltd)
http://www.moviedatabase.com/ .. a site for sore eyes.
Re: Change
Posted by Marc Slemko <ma...@worldgate.com>.
That doesn't solve anything because it just creates yet another tree,
someone these trees have to magically stay together. It is a big enough
pain maintaining minor changes to two source trees right now...
On Fri, 9 Jan 1998, Rob Hartill wrote:
>
> don't shoot me, but what about a CVS tree for commit-then-review
> and one for review-then-commit ?
>
> i.e. if I have a change I want people to review, I drop it into
> the c-t-r, people review it (don't, complain or whatever) and then
> it can be moved into the r-t-c tree later. The r-t-c tree can then
> be viewed as "stable" and safe for semi-automatic tarballing for
> release at any time. Developers would mostly use the c-t-r code,
> new-httpd testers (and there are lots of them) would us the r-t-c
> code.
>
> This is similar to FreeBSD's -current and -stable except that they
> let those two drift miles apart. If we can keep the two close together
> (in content) then it could work.
>
> --
> Rob Hartill Internet Movie Database (Ltd)
> http://www.moviedatabase.com/ .. a site for sore eyes.
>
Re: Change
Posted by Rob Hartill <ro...@imdb.com>.
don't shoot me, but what about a CVS tree for commit-then-review
and one for review-then-commit ?
i.e. if I have a change I want people to review, I drop it into
the c-t-r, people review it (don't, complain or whatever) and then
it can be moved into the r-t-c tree later. The r-t-c tree can then
be viewed as "stable" and safe for semi-automatic tarballing for
release at any time. Developers would mostly use the c-t-r code,
new-httpd testers (and there are lots of them) would us the r-t-c
code.
This is similar to FreeBSD's -current and -stable except that they
let those two drift miles apart. If we can keep the two close together
(in content) then it could work.
--
Rob Hartill Internet Movie Database (Ltd)
http://www.moviedatabase.com/ .. a site for sore eyes.
Re: Change
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 8 Jan 1998, Dean Gaudet wrote:
>
>
> On Thu, 8 Jan 1998, Jim Jagielski wrote:
>
> > Change is good.
> >
> > Example 1: The current process of posting patches and then having
> > M-ID in status. A nice change IMO would be to place the patches
> > somewhere under the CVS tree to allow easy and consistant access
> > to the patches. Change-type: Evolutionary. As far as I can recall,
> > Dean thought this sucked, even though it helped some people out.
>
> Dean thinks this sucks because it was presented as an additional duty to
> perform while patching the code as opposed to replacing the duty of
> posting the patch to new-httpd. If the proposal is really to replace the
> posting of the patch then say so, and get rid of apache-cvs and direct all
> cvs commits to new-httpd. It seems foolish for folks to subscribe to both
> lists, and if they don't subscribe to apache-cvs they may wonder what's
> going on. It's not like apache-cvs is high volume.
>
> Aren't all freebsd commits sent to the main discussion lists?
No. There are seperate cvs commit lists. Actually, about 8 or 10 of
them for different parts.
Sending to a seperate list is _good_. It is very valuable for searching.
Re: Change
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 8 Jan 1998, Jim Jagielski wrote:
> Change is good.
>
> Example 1: The current process of posting patches and then having
> M-ID in status. A nice change IMO would be to place the patches
> somewhere under the CVS tree to allow easy and consistant access
> to the patches. Change-type: Evolutionary. As far as I can recall,
> Dean thought this sucked, even though it helped some people out.
Dean thinks this sucks because it was presented as an additional duty to
perform while patching the code as opposed to replacing the duty of
posting the patch to new-httpd. If the proposal is really to replace the
posting of the patch then say so, and get rid of apache-cvs and direct all
cvs commits to new-httpd. It seems foolish for folks to subscribe to both
lists, and if they don't subscribe to apache-cvs they may wonder what's
going on. It's not like apache-cvs is high volume.
Aren't all freebsd commits sent to the main discussion lists?
> Example 2: The current review-and-commit process, which has been
> used since Day 1 is slow. A nice change would be to instead
> have commit-and-review. Change-type: Revolutionary. Dean liked it
> cause it made things easier for him.
... and makes things easier for other developers. It's far less work than
the current or the example 1 or my modified example 1.
Patching code by hand is a manual process subject to failures (due to
conflicting patches). This was one of the motivating factors for moving
to CVS ages ago.
"cvs update" on the other hand is subject only to failures when you've
made your own local modifications, in which case that's your own trouble
and you understand that by typing "cvs update". But it's pretty damn easy
to test the latest server by typing
cvs update
cd src
./Configure
make clean
make
Contrast with (and this is pretty much true of both the current system
and example 1):
cvs update
for i in patches/*; do
oh have I applied this yet? I'm not sure
patch <$i
some possibilities:
1. aw shit yeah I have
oh damn which *.orig files do I have to rename?
2. aw shit it doesn't merge
oh damn the *.rej files don't make sense
how do I back out of this one?
3. oh wow it patched
done
cd src
./Configure
make clean
make
oh damn one of those patches conflicted with another one and the
server won't even compile now (IMNSHO higher probability than in
the commit-then-review scenario)
I dunno. There seems to be a lot more room for error and frustration
with the current system -- both leading to apathy.
Dean