On Mon, Nov 6, 2017 at 12:44 PM, Jim Jagielski <j...@jagunet.com> wrote:
>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr <wr...@rowe-clan.net> 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