Von: William A Rowe Jr <wr...@rowe-clan.net> Gesendet: Mittwoch, 12. September 2018 03:15 An: httpd <dev@httpd.apache.org> Betreff: Re: 2.4.x and 2.6.x ... next steps
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<mailto:j...@jagunet.com>> wrote: We have never dropped code without requiring an actual veto, or the committee withdrawing their code. To my understanding we talk about code that “does not work” and has “issues”. So I have never seen a need to veto code in order to fix it. Fixing code can also include dropping parts of the code. I guess you are more worried that we drop the code of complete “features” from trunk. As with other stuff I think we just need to discuss on dev@ if there are “features” that have issues that need to be fixed. And if nobody pops up that wants or can fix these issues then dropping it is IMHO a valid option as well. If you want to do that via a formal veto on the original commit is another topic. I guess this is warranted for big contributions like whole modules. I think that if we as a group decide in the open that a certain feature for a new major release is undesirable for whatever reason it is fine to drop it and thus the code even from trunk if nobody is willing to work on it and maintain it. Actually the code will never be dropped. You just need to dig in the svn history to find it. I think the whole point goes more in the direction that the review on trunk is sometimes too “sloopy” so that we accumulate unfinished, buggy and untested stuff instead of having these issues solved when the code was committed and the contributor is still available and up to speed for discussion and resolution. One other approach would point in the direction to have major releases more often such that these issues are detected earlier. As proposed on this thread I guess a traversal of the stalled backport proposals for 2.4.x is a good starting point to pick up issues in trunk. I guess we need to pay some price for getting 2.5.x / trunk in a GA releasable state in order to publish 2.6.x: 1. Either we try to stabilize stuff on trunk, but this means we need to back down with new fancy ‘unstable’ commits on trunk (social rule not formal RTC). 2. Or we add that 2.5.x branch which is RTC in between trunk and 2.4.x branch and thus slow down the backports to 2.4. If there are enough people that can work on getting 2.5.x / trunk in a GA releasable state I think 1. or 2. will not take long and thus are acceptable. OTOH if doing that will become an endless story I think both approaches will create a lot of friction. Independent on which way we go we should possibly set a rough timeline for finishing this work and return to current state if it cannot be done this way in the timeline. Regards Rüdiger
