On Tue, Oct 24, 2017 at 12:39 PM, Jim Jagielski <j...@jagunet.com> wrote:
> On Tue, Oct 24, 2017 at 11:20 AM, William A Rowe Jr <wr...@rowe-clan.net> 
> wrote:
>> On Tue, Oct 24, 2017 at 8:42 AM, Jim Jagielski <j...@jagunet.com> 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.

Reply via email to