On Tue, Oct 24, 2017 at 12:39 PM, Jim Jagielski <[email protected]> wrote: > On Tue, Oct 24, 2017 at 11:20 AM, William A Rowe Jr <[email protected]> > wrote: >> On Tue, Oct 24, 2017 at 8:42 AM, Jim Jagielski <[email protected]> wrote: >>> >>> Another would be to look at some of the items currently >>> "on hold" for backporting, due to outstanding questions, >>> tech issues, more needed work/QA, etc... IMO, if these >>> backports lack "support" for 2.4.x, then I wonder how >>> "reliable" they are (or how tested they are) in the 2.5.o >>> tree. And if the answer is "we pull them out of 2.5.0" >>> then the question after that is what really *are* the >>> diffs between 2.5.0 and 2.4.x... If, however, the >>> answer is "tagging 2.5.0 will encourage us to address >>> those issues" then my question is "Why aren't we doing >>> that now... for 2.4.x". >> >> I am not doing it for 2.4.x, and will continue not to do it for 2.4.x, >> because I won't contribute to further destabilizing 2.4.x current >> releases. > > So you refuse to help stabilize the 2.4.x tree, but then complain > that the 2.4.x tree is unstable.
Because introducing unwise enhancements makes it so; because branch hygiene makes it so. I'm not going to battle either windmill, since current practice dictates that it is a losing battle. I'll continue to review and vote up bug fixes. I'll continue to push bugfixes I write at 2.4.x. I'll continue to skim enhancements for breakage that I can spot. > OK. That's fine. Your cycles are yours to use as you wish. There we go again with the personal swipes. Please speak to process and code, not people. This is exactly the point, of course. Those who wanted to maintain 2.2 did so, irrespective of what those other committers, who could not have cared less, chose to work on. And so it will be after 2.4, committers can keep maintaining 2.4, during the 2.5 cycle and beyond 2.6.0/3.0.0. Those who simply want to develop can develop.
