Fellow PMC folk... I think everyone on this list can agree that the pace of releases has slowed to a crawl; we are 6+ mos between releases of our active/stable 2.4 series, which has little if any adoption, and are equally lethargic about the actually stable-and-adopted 2.2 releases. This is a thread which we have visited before many times, but I'd like to throw a new spin on it and consider whether we have taken several group decisions, and combined them into the worst results possible from the lot of them.
My question to the group; is /repos/asf/httpd/httpd/trunk/ actually a trunk? Or is it a sandbox? All ASF projects have one goal, which is to release open source code to the public at no charge. What is currently brewing as /repos/asf/httpd/httpd/trunk/ has a version # designation, but no plan to release, and no release in several years. I would humbly submit that with no plan to release, /trunk/ is simply a sandbox, and should be svn mv'ed to the appropriate svn branch for those developers to retrieve, maintain and later advance their proposals into an actual 2.5.0 release trunk at some future date. I'm watching a ton of mental gymnastics by the few who are willing to fight with this bureaucracy to commit to a non-release trunk, plea for backport votes, then perhaps get their code into 2.4 (which is not yet even distributed by anyone other than the ASF and adopted by almost no users at all). The entire model, IMHO, is broken by mixing too many of our consensus concepts in the most inefficient manner. Here's my proposal... In 30 days, if there is no release of 2.5.0, we move /trunk/ over to the sandbox, and restore 2.4.x as the /trunk/. No RTC, simply fix it, or if it is a complex change, propose it in that sandbox, in it's own sandbox, or to the dev list. If anyone wishes to start a clock on 2.5.0, they have 30 days to produce a release. While our policy states they can do anything they like, the simplest history would be to start from 2.4.x trunk, append the patches from the sandbox 2.5 that they believe should survive, and tag and roll a candidate. If rejected, no damage. If accepted, that sandbox then becomes /trunk/ with /trunk/ relegated to /branches/2.4.x/ More importantly, during the transition, the *RM* is responsible for keeping the sandbox in sync, not the entire body of httpd committers. I'm at a loss why a half dozen active committers need to do 2x the work to maintain a single branch. And I have no question in my mind why it is down to nothing but a half dozen committers... the process and flow of the project is painful. We could launch into a whole debate over the advantages of svn vs git, but the tool isn't the problem, it is the mess of process which we have created for ourselves. So my proposal to be presented shortly as a vote would be to abandon the trunk into a sandbox to be mined for good changes, once 30 days after a vote is concluded without a release, and to revert the 2.4.x trunk to CTR. Comments and suggestions are welcome before I frame this as an actual policy vote... Cheers, Bill
