git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.4.x and 2.6.x ... next steps




Le 12/09/2018 à 03:15, William A Rowe Jr a écrit :
On Tue, Sep 11, 2018, 17:42 Graham Leggett <minfrin@xxxxxxxx> wrote:
On 11 Sep 2018, at 20:35, Jim Jagielski <jim@xxxxxxxxxxx> 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