httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Tue, 26 Nov 2002 16:12:17 GMT

On Monday, November 25, 2002, at 05:59  PM, Roy T. Fielding wrote:

> On Monday, November 25, 2002, at 04:58  PM, Aaron Bannert wrote:
>> I guess I just didn't read that much in to it. I just want
>> to see us move forward without getting bogged down in
>> misinterpreted emails and already acknowledged mistakes,
>> and to do that I'm trying to stay objective (eg. a Vote).
>>
>> To me this looks like the set of concerns:
>>
>> 1) we want 2.0 maintenance
>> 2) we want 2.1 development
>> 3) we want parallel development of each
>> 4) a bad name for a combined 2.0+2.1 CVS module is "httpd-2.0"
>> 5) having separate CVS modules means we lose future history
>> 6) creating a brand new CVS module means we lose past history
>>
>> (does this cover everyone's concerns?)
>
> Those aren't concerns -- they are answers.

Well, I was trying to list the set of things people have noted over time
so that we could come to a consensus on the whole thing. Maybe it is
too many issues at the same time, but it is difficult to deal with one
without having to deal with the others.

> One recent problem
> I've noted is that we have lost the art of phrasing votes so that
> they don't cut across several issues at once.  The vote on establishing
> separate development trees of stable and unstable versions was fine,
> but none of that implied a single new repository would be created
> with a variety of branches interwoven within it.  We can decide that
> now in STATUS.

Cool. Will you add it in? I've never claimed skill in this art. :)

>> Therefore I'm proposing that we just keep the "httpd-2.0" CVS
>> module we have for a little longer, eventually on some
>> well-in-advance forewarned flag day we rename it to something
>> more generic, like just "httpd" and then keep a readonly
>> artifact of the old "httpd-2.0" CVS module around for posterity.
>
> Too many issues at once.  Do we want the new repository in order
> to clean up legacy stuff, or simply because having 2.0 in the name
> is confusing?  In either case, httpd is the wrong name -- httpd-2
> would be okay.

Funny you should mention "httpd-2", since that was also my suggestion
at the time when the "httpd" symlink was created.

> Working within an ancient CVS module makes sense while
> directory names and the purposes of files remain essentially the same,
> but people are fooling themselves if they think CVS merge will work
> after a large-scale change such as async-io.

I personally don't want to fool with a CVS merge unless I have to. I
would think that for something like that we would just do a manual merge
with patches.

> Personally, I have a
> hard time keeping track of branch-based modifications, even though
> I know where to look in the commit message.  Maybe we could move the
> branch tag into the subject?

+1. I have the same problem, and IIRC PHP does the subject thing and I
like that.

> I don't think we have a "contract" with developers to maintain the
> httpd-2.0 module name for eternity, though the right solution is an
> alias in CVSROOT modules, not a symlink.  FYI, a symlink is *never*
> appropriate under /home/cvs, for any reason, because it doubles
> the committable space while at the same time bifurcating access
> control, commitlogs, notices, etc.  It is better to break existing
> commit access and force people to checkout a fresh tree.

So CVSROOT/modules aliasing will also alias commit logs, access control,
etc? I also suggested using this method, but thought it was merely 
another
form of symbolic linking specific to CVS. If it does everything then
that's obviously the way to go.

> But, as OtherBill suggested, my main objection was that the changes
> were made without discussion, and hence without a chance for me to
> point out that symlinks are bad under /home/cvs, and it seemed better
> to revert that change than try to accommodate it the right way with
> changes to modules, avail, and apmail.  I still prefer new modules
> for 2.1 and 2.2 simply because I know the performance will be better,
> but that won't be substantial for another six months or so of dabbling,
> and I wasn't even planning to vote on that because I am more
> interested in 3.0.

Call it what you will, what features are you referring to?

-aaron


Mime
View raw message