Le 12/09/2018 à 03:15, William A Rowe Jr a écrit :
On Tue, Sep 11, 2018, 17:42 Graham Leggett <minf...@sharp.fm
<mailto: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.
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)
CJ
