OSDir


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

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


On Tue, Sep 11, 2018 at 10:07 PM Christophe JAILLET
<christophe.jaillet@xxxxxxxxxx> wrote:
>
> Le 11/09/2018 à 20:35, Jim Jagielski a écrit :
> > I'd like for us to seriously consider the next steps
> > related to the future of httpd.

++1

> > This is what I propose:
> >
> >    o Later on this week I svn cp trunk over to branches/2.5.x
> My only comment is that, from my personal point of view, we should start
> from branches/2.4.x and not from trunk.
> See below why.
>
> >    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

LGTM, thanks for being clear on this!

> > 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)
>
> This is why I think that backporting (and/or cleaning trunk) is easier
> to manage than removing "experiments".
> We know, and eventually can vote to have more reviews if we backport.
> We can have "experiments" stay in 2.5.x/2.6 if no-one pays attention to it.

This would let trunk in a less controlled state than Jim's proposal
IMHO, complicating future backports to 2.6.x.
I wish we could "cleanup" trunk from our work/findings on what 2.6
should be, there is probably few gains to let things in trunk if they
don't fit in 2.6.

>
> I have in mind a discussion between Yann and William about a potential
> past issue that could have been re-introduced by a recent optimization.
> There was no clear status if it was an issue or not, but if it was, it
> would silently be re-introduced.
> (I've not been able to find the corresponding mails, will try to dig
> further tomorrow evening)

Possibly: https://lists.apache.org/thread.html/%3CCAKQ1sVNw_VDpBZk6C+F30Y5nBhHosbbWT_FUbtTSnC+R7MBiTA@xxxxxxxxxxxxxx%3E
?
That was a proposal (nothing committed), I don't think the regression
suspected by Bill was there, but had to work on something else so
couldn't test it... and then forgot about it :/
Thanks for the reminder ;)

Anyway, I see what you mean but is it better to leave such potential
bugs in trunk? Wider 2.5 testing and early 2.6 versions are meant to
catch them IMO.


Regards,
Yann.