On Fri, Oct 13, 2017 at 8:25 AM, Jim Jagielski <j...@jagunet.com> wrote:
> Why lump 2.5.0 into all this?
> There is no rational reason to force connect 2.4.29 and 2.5.0
> Tag 2.4.29 and leave 2.5.0 alone until people discuss it. Until then
> I will veto any foolishness about 2.5.0-whatever.
Good work, you helped established a foundation with two simple
premises, that no code changes can happen without a group
consensus, while no individual can ever block a release, that vote
is not subject to veto; simple majority.
It's only taken you 18 years to single-handedly undo that? Surely
you know there is no such thing as "Your Esteemed" veto. That
was actually the basis for my -0 on 2.4.28, I determined it was an
unwise release (little did we know), but left it at that... any -1 was
going to have no effect whatsoever unless the RM agreed it was
an unwise tag.
2.5.0-[alpha|beta] serves a number of very useful purposes;
* Is trunk buildable by most? Is it stable? Is it a broken playground
of cruft that is not releasable?
* By my count, four rather twisted backports are proposed to 2.4.x
none of which have seen any testing whatsoever. Bold suggestion
that these should be pushed on users in the current "maintenance"
branch that users are relying on. An alpha/beta of these features
pushes them to the forefront and may win huge acceptance or
* Several major Linux distributions are approaching a glide path
towards 2018 final decisions on httpd reversioning; Ubuntu LTS
and RHEL 9 are likely to be locked in by year end for the next
quarter decade. Our lack of momentum spells zero chance to
move toward fixes of longstanding deficiencies.
* Big news splash on major ssl enhancements that are unreleased.
In theory, the suggestion to alpha the code would have collided
with a news release on the subject in a good way (not withstanding
the late review of your specific issue and appreciation that it was
a much broader issue with invalid C grammar AC tests.)
* What needs to come next? What third party modules are already
broken? What changes are third party developers clamoring for?
Oh, and we don't ship snapshots, by definition. So, no alpha/beta
cycle results in a lose lose proposition for our consumers.
But with your dismissive attitude, we might as well presume, since
you are rewriting the project and foundation ruleset, that in your
esteemed wisdom, httpd will no longer evolve, so any suggestion
that httpd could be better than it is today is lost on this mailing list
under your esteemed supervision and new rulemaking.
Please reconsider my rational for submitting this suggestion, and
rethink your basis for opposing it.