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

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

In my estimation, cleaning up trunk (or a copy of it) via RTC will take forever, at least.

And while that continues, any bugfix can only be done in trunk. We then need 2(!) RTC proposals and votes per fix if it affects 2.4.x. (Which, until 2.6 is out and gets adopted, will be the case almost all of the time.)

We do not even find enough people to look at the proposals for 2.4.x. It's easier to find people outside the project to test fixes in their production systems. 

Short: I do not believe this can work.


> Am 11.09.2018 um 20:35 schrieb Jim Jagielski <jim@xxxxxxxxxxx>:
> I'd like for us to seriously consider the next steps
> related to the future of httpd.
> In trunk we have some stuff that can be easily, or, at
> least, *somewhat* easily backported to 2.4.x, and I
> personally think that we should do that. But we also
> have some items which cannot be backported due to API/ABI
> concerns, and some of these are pretty useful things.
> And finally, we have some things in trunk that will likely
> need to be majorly fixed or else scrapped.
> The 1st thing we need to do is classify those things
> within trunk. We then need to backport what we can,
> and should, and then make progress on a 2.6.x release
> (please note, I am using shorthand here... yes, I know
> what we *really* do is a 2.5.x which then goes to 2.6.x
> but I'm hopeful we all know what I mean).
> This is what I propose:
>  o Later on this week I svn cp trunk over to branches/2.5.x
>  o That branch becomes the initial source for 2.6.x
>  o trunk remains CTR, whereas branches/2.5.x becomes RTC
>    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
> A combination of trunk's STATUS and 2.4.x's STATUS will
> become the STATUS for 2.5.x... see below for the why (but
> basically that file will serve as the place where those
> above "classifications" will be documented).
> The main goal is that this creates a somewhat "stable"
> 2.5.x branch which can be polished but as well serve as
> the source for backports. Additional development continues
> on trunk w/o mussing up 2.5.x... but there is also a path
> that stuff in trunk can end-up in 2.6.x. In also allows us
> to remove "experiments" in the old trunk (and now 2.5.x)
> which are broken or, at least, doesn't have enough support
> to warrant being released (a glance thru 2.4.x's STATUS file
> for backports which are stagnated, etc provide some clues
> on what those could be... at the least, this will provide
> incentive to address those concerns or revert those additions)
> For me, the main push for this are some of the various async
> improvements in trunk that, at least from what I can tell,
> simply cannot be backported. It is possible that those improvements
> will be the primary and almost-singular distinction between
> 2.4.x and 2.6.x after all is said and done, but who knows...
> Thoughts? Comments?