httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: End of the road of 2.2.x maintenance?
Date Mon, 16 May 2016 16:43:00 GMT
On Wed, May 11, 2016 at 2:31 PM, Mark Blackman <mark@exonetric.com> wrote:

>
> On 10 May 2016, at 21:38, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>
> Are we ready to start the 12 month countdown as of the next/final bug
> fix release of 2.2, and highlight this in both the 2.2 and 2.4 announce
> broadcasts?
>
> Feedback desired
>
> As a big consumer of Apache 2.2 in my day job, where we are obliged to
> track Apache’s policies very closely, I would prefer to delay this a bit.
> When Apache announces the formal end-of-life date of 2.2, we will be
> required to engineer the migration of 6000+ wildly diverse sites to Apache
> 2.4 to meet internal audit policies. I would propose the 12 month countdown
> starts no earlier than Jan 2017 (as a consumer).
>

An underlying issue from my own perspective is that OpenSSL 1.0.1 support
ends this year on December 31st. If there were ever a critical time to
update a deployment stack from end-to-end, the termination of support for
the highest-risk component would be the time to do so.

>From an operational perspective, the historical trend has been a 3 year
rolling deprecation of physical commodity hardware systems (although not
for big iron). It seems within the scope of modern cloud and virtualized
deployments, that window may be growing  shorter - with many apps
provisioned on their own discrete client environments.

The larger issue from our perspective, as an open-source collaboration -
not as a commercial distributor, is that it is hard to support users who
have insisted on deploying new httpd 2.2 instances over these past three
years. 2.4.1 was released literally 4 years ago. Users who insist on
deploying software which is already 3 to 4 years out of date need to seek
some paid commercial mitigation in terms of support, or assume the risk of
supporting the source code themselves (it is open source, when it breaks we
all get to keep all of the pieces and fix them as we like.)

This isn't really an appropriate role for ASF projects and volunteers. The
2.4 release a radically different situation than Gnome 3, for example,
which led to a split of opinion and dedicated communities interested in
continuing the legacy of Gnome 2. The migration path from 2.2 to 2.4 is not
painless, but is really not complex or unfamiliar. Modules are included to
ease the transition, particularly the transition of auth schemas.


> What’s the cost of maintaining (but maybe not updating) Apache 2.2?
>

Finding the volunteers among our committers and PMC members willing to
continue to evaluate and triage security reports, backport fixes, creating
release candidates and at least 3 PMC members willing to review and vote on
a release. And those costs are deducted from the opportunity to further
support the 2.4 branch and advance the development trunk.

Already, a rather large majority of our committers have abandoned the 2.2
maintenance branch and focus their attentions on trunk (2.6/3.0 future
release) and the 2.4 maintenance branch. So this question is largely
directed to the dedicated minority of committers who have continued to
service this branch throughout its 10 years.

If there are 3 clear votes against moving toward EOL at this time from our
PMC, this poll would fail (there is a big enough contingent to keep 2.2
releases alive for an extended period of time). Without 3 PMC members
reviewing release candidates, 2.2 would already be EOL by default.

Note that our choice to end ASF development of the 2.2 maintenance branch
only indirectly impacts the decision by vendors to end or continue
commercial support and security fixes to the software. This is why I'd
suggested that we may continue to collect security patches to the final
2.2.x release, as we have several distributors represented here who have a
lot to gain a lot by collaborating and reviewing the efficacy of security
patches as a community. As an OSS project, we would simply elect not to
craft a "release" of that software following our EOL consensus date. Two
vendor-supported examples, RHEL 6 still ships 2.2.15 and SLES 12 still
ships 2.2.22 - absolutely ancient software that they choose as a business
model to patch and update for key defects. That's a byproduct of their
decisions, not ASF decisions.

Hope this adds clarity to the suggested EOL, you can go back through the
list archives to see how we arrived at the decisions to end maintenance of
the 2.0, and 1.3 releases. It's always better to work as a group to that
end date, than to let an OSS project reach that point unannounced by
attrition of participants.

Yours,

Bill

Mime
View raw message