Thx for the clarification.

> On Nov 6, 2017, at 2:34 PM, William A Rowe Jr <> wrote:
> On Mon, Nov 6, 2017 at 12:44 PM, Jim Jagielski < 
> <>> wrote:
>>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr <> wrote:
>>> Reiterating again, that we disagree about who our preferred
>>> approaches are serving and they are disingenuous toward.
>>> Again, a value judgement.
>> Assuming we go ahead and tag 2.5.0, what is your intention
>> related to 2.4.x? My understanding is that your desire is to
>> place it under "maintenance mode", that is, no functional
>> backports to 2.4.x.
>> Is this correct?
> No, that's a misunderstanding... my desire is to have 2.4.x stable,
> but my ability to do this (short of technical vetoes of ABI-breaking
> changes) is non-existent.
> My voting or not voting on backports has nothing to do with what
> other committers choose to do. Just as some chose to have nothing
> to do with backporting to 2.2.x for years, others chose to propose
> and commit backports to 2.2.x in those years.
> 2.2.x went into an effective feature-freeze when a majority of the
> httpd project voted that it be frozen, and then began rejecting
> destabilizing changes. 2.2.x went EOL when a vast majority of
> the httpd project declared they would no longer participate in
> its maintenance after {date}. I structured it as a poll so we would
> all understand at what point there would not be three participants
> in future maintenance releases.
> My individual desire is irrelevant.
>> To be honest, I don't care at all what happens re: trunk and
>> the 2.5.0 tag, etc as long as it does NOT restrict what we
>> can do for 2.4.x. My fear is that one goal behind tagging 2.5.x
>> is hamstringing 2.4.x.
> Which became justification for hamstringing all future releases?
>> So, for the record, just so we are all clear, what is your desire/goal
>> in all this as far as 2.4.x is related?
> That 2.4.x needs a minimum of three committers to continue to make
> releases, that is project policy. If 2.4.x ends up being a 20-year LTS
> maintained release, it reflects that there are 3+ committers who make
> make that happen, not that there is or isn't demand for it.
> And if maintainers are interested in specific trunk/ efforts, then by
> all means propose and adopt those for backport. Those who have
> an itch to scratch should scratch that itch.
> Remember I have no more power to block a 2.4.x branch release than
> another committer could veto a trunk release. And we have nothing but
> technical justification to base rejecting either a new submission or some
> backport proposal.
> Beyond that, I'll vote up some good bugfix backports, veto breaking
> changes, and otherwise ignore the stream of potentially unwise
> enhancements and leave it to those who want to spend their free
> cycles to evaluate those proposals, and make those calls. I expect
> 2.4.x to eat much less of my own time, going forwards.

Reply via email to