You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2016/05/10 20:38:25 UTC
End of the road of 2.2.x maintenance?
It's been a year, and seems to be a good time to revisit this topic
while those folks who are present at ApacheCon can discuss f2f
the merits of bringing the 2.2.x chapter to a close, and share their
thoughts back here on-list.
According to http://w3techs.com/technologies/history_details/ws-apache/2
the inflection point of a majority of 2.4 instances over 2.2 appears
to occur about 9 months from now.
OpenSUSE 13.1 adopted 2.4 way back in Nov of '13.
Ubuntu - 14.04 LTS, and Debian 8 (Jessie) switched to 2.4 in April '14.
RHEL / CentOS 7 are well over a year old, adopted 2.4 in June '14.
Fedora 18 shipped 2.4 way back in Jan '13.
E.g. every user of the broadly distributed Linux releases will have had
three full years to adopt 2.4 by June of 2017. I expect the BSD world
looks similar (modulo any Apache License 2.0 stupidity we are all
too familiar with.) If someone in the BSD, Solaris and other spheres
wants to chime in here with those milestones, that would be great.
I am prepared to RM a final bug-fix release of 2.2 in conjunction with
the next 2.4 release effort, to gather in any final requests for fixes
before we move to a 12-month, security-fixes-only window on that branch.
Once those 12 months expire, as we've done with 1.3 and 2.0, there's
the possibility that relatively few committers would collect some critical
patches/apply-to-2.2.xx final security fixes, but no further releases would
occur.
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?
I'm hoping we conclude some fixes of 2.4 scoreboard regressions and
get to the point of releasing 2.4 with mod_proxy_http2 sometime within
the next month or so, and that we can reach a consensus about how
we will proceed on the 2.2 branch, before we get to that release.
Feedback desired,
Cheers,
Bill
Re: End of the road of 2.2.x maintenance?
Posted by Noel Butler <no...@ausics.net>.
On 12/05/2016 05:13, Ruediger Pluem wrote:
> On 05/10/2016 10:38 PM, William A Rowe Jr wrote:
>> It's been a year, and seems to be a good time to revisit this topic
>> while those folks who are present at ApacheCon can discuss f2f
>> the merits of bringing the 2.2.x chapter to a close, and share their
>> thoughts back here on-list.
>>
>> According to
>> http://w3techs.com/technologies/history_details/ws-apache/2
>> the inflection point of a majority of 2.4 instances over 2.2 appears
>> to occur about 9 months from now.
>>
>> OpenSUSE 13.1 adopted 2.4 way back in Nov of '13.
>>
>> Ubuntu - 14.04 LTS, and Debian 8 (Jessie) switched to 2.4 in April
>> '14.
>>
>> RHEL / CentOS 7 are well over a year old, adopted 2.4 in June '14.
>> Fedora 18 shipped 2.4 way back in Jan '13.
>>
>> E.g. every user of the broadly distributed Linux releases will have
>> had
>> three full years to adopt 2.4 by June of 2017. I expect the BSD world
>> looks similar (modulo any Apache License 2.0 stupidity we are all
>> too familiar with.) If someone in the BSD, Solaris and other spheres
>> wants to chime in here with those milestones, that would be great.
>>
>> I am prepared to RM a final bug-fix release of 2.2 in conjunction with
>> the next 2.4 release effort, to gather in any final requests for fixes
>> before we move to a 12-month, security-fixes-only window on that
>> branch.
>> Once those 12 months expire, as we've done with 1.3 and 2.0, there's
>> the possibility that relatively few committers would collect some
>> critical
>> patches/apply-to-2.2.xx final security fixes, but no further releases
>> would
>> occur.
>>
>> 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?
>>
>> I'm hoping we conclude some fixes of 2.4 scoreboard regressions and
>> get to the point of releasing 2.4 with mod_proxy_http2 sometime within
>> the next month or so, and that we can reach a consensus about how
>> we will proceed on the 2.2 branch, before we get to that release.
>>
>> Feedback desired,
>
> Sounds like a sensible plan.
>
> Regards
>
> R�diger
Agreed
(Slackware moved to 2.4 in Sept 2012)
--
If you have the urge to reply to all rather than reply to list, you best
first read http://members.ausics.net/qwerty/
Re: End of the road of 2.2.x maintenance?
Posted by Daniel Ruggeri <dr...@primary.net>.
On 2016-05-11 14:13, Ruediger Pluem wrote:
> On 05/10/2016 10:38 PM, William A Rowe Jr 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?
>>
>> I'm hoping we conclude some fixes of 2.4 scoreboard regressions and
>> get to the point of releasing 2.4 with mod_proxy_http2 sometime within
>> the next month or so, and that we can reach a consensus about how
>> we will proceed on the 2.2 branch, before we get to that release.
>>
>> Feedback desired,
>
> Sounds like a sensible plan.
>
> Regards
>
> R�diger
+1
--
Daniel Ruggeri
Re: End of the road of 2.2.x maintenance?
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/10/2016 10:38 PM, William A Rowe Jr wrote:
> It's been a year, and seems to be a good time to revisit this topic
> while those folks who are present at ApacheCon can discuss f2f
> the merits of bringing the 2.2.x chapter to a close, and share their
> thoughts back here on-list.
>
> According to http://w3techs.com/technologies/history_details/ws-apache/2
> the inflection point of a majority of 2.4 instances over 2.2 appears
> to occur about 9 months from now.
>
> OpenSUSE 13.1 adopted 2.4 way back in Nov of '13.
>
> Ubuntu - 14.04 LTS, and Debian 8 (Jessie) switched to 2.4 in April '14.
>
> RHEL / CentOS 7 are well over a year old, adopted 2.4 in June '14.
> Fedora 18 shipped 2.4 way back in Jan '13.
>
> E.g. every user of the broadly distributed Linux releases will have had
> three full years to adopt 2.4 by June of 2017. I expect the BSD world
> looks similar (modulo any Apache License 2.0 stupidity we are all
> too familiar with.) If someone in the BSD, Solaris and other spheres
> wants to chime in here with those milestones, that would be great.
>
> I am prepared to RM a final bug-fix release of 2.2 in conjunction with
> the next 2.4 release effort, to gather in any final requests for fixes
> before we move to a 12-month, security-fixes-only window on that branch.
> Once those 12 months expire, as we've done with 1.3 and 2.0, there's
> the possibility that relatively few committers would collect some critical
> patches/apply-to-2.2.xx final security fixes, but no further releases would
> occur.
>
> 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?
>
> I'm hoping we conclude some fixes of 2.4 scoreboard regressions and
> get to the point of releasing 2.4 with mod_proxy_http2 sometime within
> the next month or so, and that we can reach a consensus about how
> we will proceed on the 2.2 branch, before we get to that release.
>
> Feedback desired,
Sounds like a sensible plan.
Regards
R�diger
Re: End of the road of 2.2.x maintenance?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, May 16, 2016 at 1:26 PM, Gregg Smith <gl...@gknw.net> wrote:
> On 5/16/2016 11:03 AM, Eric Covener wrote:
>
>> On Tue, May 10, 2016 at 1:38 PM, 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?
>>>
>> One shortcoming of a 12 month countdown is that some folks will not be
>> able to plan/pitch/budget/execute a migration in 12 calendar months
>> because of bad timing.
>>
>> As long as we're not committing to releases in this window, I'd
>> personally be okay with pushing out to 18 months re: the later
>> feedback in this thread. I don't feel too strongly about> 12 months
>> notice, but I will still have a 2.2-derivative in support beyond that
>> window anyway.
>>
>
> We should just pick a date right now (say 31/12/2017) and begin announcing
> (website/download page/mail lists) it now. Include that one last release
> will come out before the end of the year and it will be patches only after
> final release and until EOL date. That is 18 and a half months to EOL with
> a final release within 6 and a half. This should leave any admin time to
> plan/pitch/budget/execute a migration and give everyone a firm date to EOL
> to plan around.
>
To square this circle... I had expect that the 'final release' for httpd
2.2 would
be based on the need for a security fix release, and expected that this may
happen as many times over that year long period as were necessary.
So from the 'next release' (using that release as a vehicle to make these
important announcements) throughout a fixed period, they should be able
to get security 'releases' for that period as part of a full tarball.
That's the model that we've observed, that the Tomcat project and other ASF
efforts have observed. It isn't cast in stone, but it seems to have been
workable.
If there were no significant security issues, we would probably have no
further
release candidates tarred and rolled and voted on.
Perhaps what Eric and Gregg are asking for is a longer 'official window' of
our
offering security patches as incidents come up? E.g. after the one year EOL
period of creating security releases, we would commit to offering security
fix
backports to 2.2.x over the following 6 mos? 1 year? These would all be
noted
under http://httpd.apache.org/security/vulnerabilities_22.html - they would
not
be 'releases' - would not require 3 PMC +1's, they could be provided so
long
as a committer wanted to prepare the backported patch, and would be subject
to discussion on security@ before publication, and discussion on dev@ after
they are publicized/disclosed. Then it becomes a matter of how long we
have a group of committers dedicated to making these happen, and whether
that group can agree upon a timeframe we can communicate to users.
WDYT? I read my proposal, Gregg's and Eric's as trying to state sort
of the same thing in three different ways, and I'd like to offer users a
single
statement that accomplishes these aligned but differently-worded goals.
Re: End of the road of 2.2.x maintenance?
Posted by Gregg Smith <gl...@gknw.net>.
On 5/16/2016 11:03 AM, Eric Covener wrote:
> On Tue, May 10, 2016 at 1:38 PM, 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?
> One shortcoming of a 12 month countdown is that some folks will not be
> able to plan/pitch/budget/execute a migration in 12 calendar months
> because of bad timing.
>
> As long as we're not committing to releases in this window, I'd
> personally be okay with pushing out to 18 months re: the later
> feedback in this thread. I don't feel too strongly about> 12 months
> notice, but I will still have a 2.2-derivative in support beyond that
> window anyway.
We should just pick a date right now (say 31/12/2017) and begin
announcing (website/download page/mail lists) it now. Include that one
last release will come out before the end of the year and it will be
patches only after final release and until EOL date. That is 18 and a
half months to EOL with a final release within 6 and a half. This should
leave any admin time to plan/pitch/budget/execute a migration and give
everyone a firm date to EOL to plan around.
Re: End of the road of 2.2.x maintenance?
Posted by Eric Covener <co...@gmail.com>.
On Tue, May 10, 2016 at 1:38 PM, 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?
One shortcoming of a 12 month countdown is that some folks will not be
able to plan/pitch/budget/execute a migration in 12 calendar months
because of bad timing.
As long as we're not committing to releases in this window, I'd
personally be okay with pushing out to 18 months re: the later
feedback in this thread. I don't feel too strongly about > 12 months
notice, but I will still have a 2.2-derivative in support beyond that
window anyway.
Re: End of the road of 2.2.x maintenance?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, May 11, 2016 at 2:31 PM, Mark Blackman <ma...@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
Re: End of the road of 2.2.x maintenance?
Posted by Mark Blackman <ma...@exonetric.com>.
> 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?
>
> I'm hoping we conclude some fixes of 2.4 scoreboard regressions and
> get to the point of releasing 2.4 with mod_proxy_http2 sometime within
> the next month or so, and that we can reach a consensus about how
> we will proceed on the 2.2 branch, before we get to that release.
>
> 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).
What’s the cost of maintaining (but maybe not updating) Apache 2.2?
Cheers,
Mark
Re: End of the road of 2.2.x maintenance?
Posted by Kurt Newman <ku...@cpanel.net>.
I’m guessing this e-mail is primarily focused on the dev side of things.
However, from a distributing side, cPanel’s migration from 2.2 to 2.4 for our customers was, for the most part, a non-eventful blip.
This isn’t meant to be a boasting seminar, but more of an appreciation for the great migration docs that helped us easily address the sticking points.
As a point of feedback, one of our biggest saviors was mod_access_compat. This addressed an issue that impacted our customer's customizations; a facet that is out of our control.
Providing security back ports is certainly a welcome prospect, and providing them for a year before going EOL seems quite reasonable.
Thanks
> On May 10, 2016, at 1:38 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> It's been a year, and seems to be a good time to revisit this topic
> while those folks who are present at ApacheCon can discuss f2f
> the merits of bringing the 2.2.x chapter to a close, and share their
> thoughts back here on-list.
>
> According to http://w3techs.com/technologies/history_details/ws-apache/2 <http://w3techs.com/technologies/history_details/ws-apache/2>
> the inflection point of a majority of 2.4 instances over 2.2 appears
> to occur about 9 months from now.
>
> OpenSUSE 13.1 adopted 2.4 way back in Nov of '13.
>
> Ubuntu - 14.04 LTS, and Debian 8 (Jessie) switched to 2.4 in April '14.
>
> RHEL / CentOS 7 are well over a year old, adopted 2.4 in June '14.
> Fedora 18 shipped 2.4 way back in Jan '13.
>
> E.g. every user of the broadly distributed Linux releases will have had
> three full years to adopt 2.4 by June of 2017. I expect the BSD world
> looks similar (modulo any Apache License 2.0 stupidity we are all
> too familiar with.) If someone in the BSD, Solaris and other spheres
> wants to chime in here with those milestones, that would be great.
>
> I am prepared to RM a final bug-fix release of 2.2 in conjunction with
> the next 2.4 release effort, to gather in any final requests for fixes
> before we move to a 12-month, security-fixes-only window on that branch.
> Once those 12 months expire, as we've done with 1.3 and 2.0, there's
> the possibility that relatively few committers would collect some critical
> patches/apply-to-2.2.xx final security fixes, but no further releases would
> occur.
>
> 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?
>
> I'm hoping we conclude some fixes of 2.4 scoreboard regressions and
> get to the point of releasing 2.4 with mod_proxy_http2 sometime within
> the next month or so, and that we can reach a consensus about how
> we will proceed on the 2.2 branch, before we get to that release.
>
> Feedback desired,
>
> Cheers,
>
> Bill