On Tue, Sep 11, 2018 at 10:07 PM Christophe JAILLET <christophe.jail...@wanadoo.fr> 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+r7mb...@mail.gmail.com%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.
