On Wed, May 11, 2016 at 2:31 PM, Mark Blackman <m...@exonetric.com> wrote:
> > On 10 May 2016, at 21:38, William A Rowe Jr <wr...@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
