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 >better. 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 httpd.apache.org/docs-2.0 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. Bill
