httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Branch of docs tree: Re: Authentication in 2.0
Date Mon, 28 Oct 2002 04:47:26 GMT
At 09:35 PM 10/27/2002, Rich Bowen wrote:
>On Sun, 27 Oct 2002, William A. Rowe, Jr. wrote:
>> MAIN branch - current development, 2.1 stays here.
>>   \--- APACHE_2_0_BRANCH [when we declare 2.1, we 'freeze' 2.0]
>>      \--- APACHE_2_2_BRANCH [as we prepare to release 2.2, we branch]
>I have had very little luck in the past with trying to to branches in
>cvs. I expect it's not hard, if there is someone at the helm that knows
>more about cvs than I. So, in general, this seems like a good idea, and
>I know that a lot of projects operate this way, and it seems to work
>really well.

It does.  Of course this is based on real practice.  The most aggravating
thing is trying to maintain 'new development' parked off on a branch.
Branches should be reserved for 'known states', not the unknown, wild
west of httpd development.  That's why I've phrased the questions in
STATUS as I have, where new-dev is always parked on the MAIN branch.

Several of us would be happy to walk other committers through the
process of committing their accepted patches back to other branches.
I work within branches all day, they really aren't that dark and scary.

However, if the list votes to accept the stable/dev odds-evens, and
chooses not to branch, we can look at the multiple-tree solution.

Another nit about branches, the httpd-2.0 cvs name begins to be sort
of silly.  But better an odd name than confuse every script rsync'ing
to httpd-2.0.  Maybe by 3.0 we will decide on a new repository.

>As with the 1.3/2.0 docs split, I'd be concerned about older branches
>getting maintained. There are a lot of people using 1.3 still, but the
>docs are far inferior to the 2.0 docs in many ways, and almost nobody is
>working on them. I guess the thinking is that once we have moved on to
>the next version, nothing needs to be done to the older version of the
>docs, but my theory tends to be that documentation can *always* be made

Of course.  This is the same with the older code, as well.  Security patches
happen.  Bugs get fixed.  There is nothing stopping good code or docs from
being applied to the old versions, just testing or proofreading.

The idea is to keep the 'wild west' of proactive httpd development (and that
would include httpd-docs development, too!) exactly where it is today.
After vetting/voting, changes that don't break compatibility are committed 
to the stable, and even prior releases.

ALL this depends on httpd relying on a stable APR release.  That side of
the wall is getting very close, and is well defined as of apr-1.0 to maintain
the sort of backwards compatibility that the new proposal requires.

>I appear to have more concerns than solutions. Right now, we are in a
>situation where people are coming to the site
>and getting answers that are just wrong for them, and clearly that has
>to get addressed first.

Yes, this has to be resolved.  We began debate, but the list got -very-
quiet on the topic this week.  Is that because we all agree?  Is that just
folks feeling they are being railroaded into adopting this change? Is it
nothing but too much busyness and not enough time to comment?

I'm not psychic, so I'm floating the issue in STATUS for consideration.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message