On Tue, Sep 11, 2018, 17:42 Graham Leggett <minf...@sharp.fm> wrote: > On 11 Sep 2018, at 20:35, Jim Jagielski <j...@jagunet.com> wrote: > > > This is what I propose: > > > > o Later on this week I svn cp trunk over to branches/2.5.x >
-1 ... Veto on the basis of project bylaws. Propose a revision for voting. > o That branch becomes the initial source for 2.6.x > As practiced in 2.1 and 2.3, trunk, forked to 2.6, is the basis for release branches. > o trunk remains CTR, whereas branches/2.5.x becomes RTC > The alpha/beta branches 2.1, 2.3 were never RTC. Veto based on project guidelines. > ala 2.4.x (ie: using STATUS and specific, targeted > > backport requests). > > o Backports to 2.4.x only come from 2.5.x > 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.
