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.
So CVSROOT/modules aliasing will also alias commit logs, access control,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.
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
