httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Tue, 26 Nov 2002 01:59:30 GMT
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.  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.

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

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.

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.


View raw message