> o We then release a 2nd alpha from branches/2.5.x
> o We get 2.5.x into a releasable stage, whereas we
> svn mv branches/2.5.x to branches/2.6.x

+1.

-1. svn cp trunk 2.6.x.

To clarify the above, this describes what we did last time
when we went from 2.2 to 2.4.

You are entirely misinformed.

When we went from 2.2 (and 2.0) we remained on
trunk.

2.3 (and 2.1) was unstable, API's changed, MMN
major was bumped every time it was a breaking change.

The code on trunk is always CTR.

When we went from 2.3 (and 2.1) we forked trunk.

The code following the first GA release is RTC.

Nothing
about the above is out of the ordinary based on what we’ve
done in the past.

No, we have never begun a new major.minor branch
as RTC.

We have never dropped code without requiring an
actual veto, or the committee withdrawing their code.

This is an attempt to turn httpd into an RTC
project.

This is an attempt to discard the work of all
committers who were told their code wouldn't be included until
the next version major.minor. Complete disenfranchisement via
a pocket veto of all changes.

If this is desirable, hold a discussion and then
vote on project bylaws/guidelines revisions to make that
happen.

If it desireable, hold a vote to discard trunk
altogether, svn rm it, and replace it with 2.4.x branch.

The very idea that this is how httpd (or sibling
projects such as apr or Perl) have ever conducted ourselves is
absurd.

If you want an example of how this goes wrong
and how it has been addressed elsewhere, the OpenSSL project
git history is a good place to start.

But let's not start introducing fictions that
httpd project has followed the track above. During 2.4.0
phase, we did in fact drop out the apreq API by backing up to
before that addition, based on the belief at that time that it
was not mature enough. Otherwise the RTC trunk 2.3.x became
CTR 2.4.x branch.

I don't have in mind all this history of the past releases.
Should 2.<odd> be CTR and 2.<even> RTC is just fine to
me, even if I personally prefer RTC. My goal is not to slow done
anything or prevent any new feature to be released. RTC, in my mind,
is safer, that's all I mean.

As you have already noted too many times, nearly all recent 2.4.x
releases have introduced some regressions.
This is sad and I wouldn't like 2.6 to be worse because of a lack of
review/acceptance in new features.

RTC doesn't prevent regression (all backports in the recent 2.4.x
have been reviewed and voted). It may catch some.

If the idea that 2.6 may introduced some issues and that the 2.5
cycle is there to try to fix as many of them as possible, this is
fine to me.

As already said in another reply, all items in "PATCHES/ISSUES THAT
ARE BEING WORKED" (i.e. un-finished?) and "PATCHES/ISSUES THAT ARE
STALLED" (i.e. with issues or disagreements?) in 2.4.x/STATUS would
be "silently" accepted.
That's my only concern.
(and building afterwards, from scratch, the list of all disruptive
modifications can be painful, I guess)