[RESULTS] [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[William A Rowe Jr]

On Wed, May 25, 2016 at 10:11 AM, William A Rowe Jr 
wrote:

>
> So let's try this... would 2.2.x maintainers and PMC folks please answer
> this
> poll -if- you have an intention to help throughout the wind-down of 2.2.x,
> since
> this is all predicated on having committed-committers to participate.
> This isn't
> to say folks refuse to participate after the time period you offer, but
> for how long
> you are personally prepared to participate.  [If you aren't a 2.2.x legacy
> branch
> participant, testing RCs or applying backports, then no response is
> needed.]
>
>  *) I intend to help maintain/test 2.2.x releases over the next [] mos
>

Thanks for all your feedback... if my tally is correct;

6 mos 12 mos 18 mos
covener covener covener
wrowe
rpluem
druggeri
rjung
jorton wrowe
rpluem
druggeri
rjung
jorton
gsmith


>
>  *) I intend to backport/review 2.2.x security patches over the next
> [] mos
>


6 mos 12 mos 18 mos
drugerri
covener
rjung
yann drugerri
covener
rjung
yann drugerri
covener
rjung
yann
wrowe
rpluem
jaillet
jorton wrowe
rpluem
jailletc36
jorton
gls

It seems we can safely call out the following in the 2.4.21 and future 2.2.x
releases;

"The Apache Web Server Project will continue to provide maintenance
releases of the 2.2.x flavor through June of 2017, and will provide some
security patches beyond this date through at least December of 2017.
Minimal maintenance patches are expected throughout this period,
and users are strongly encouraged to complete their transitions to
the 2.4.x flavor of httpd on an expedited basis to benefit from a larger
assortment of bug fixes, software robustness and new features."

Or something along those lines.

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Joe Orton]

On Wed, May 25, 2016 at 10:11:40AM -0500, William A Rowe Jr wrote:
> you are personally prepared to participate.  [If you aren't a 2.2.x 
> legacy branch participant, testing RCs or applying backports, then no 
> response is needed.]
> 
>  *) I intend to help maintain/test 2.2.x releases over the next [12] mos
> 
>  *) I intend to backport/review 2.2.x security patches over the next [12]
> mos

I can certainly test a "final"-ish 2.2 release in this timescale though 
I may need a prod :)

For selected (Critical) security issues we'll still be working on 2.2 
backports through to 2020 for RHEL6, so likely I or somebody else @ Red 
Hat will be willing to co-operate upstream on backports, if only in 
patches/ or whatever.

Regards, Joe

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Christophe JAILLET]

*) I intend to help maintain/test 2.2.x releases over the next [ 0 ] mos

*) I intend to backport/review 2.2.x security patches over the next [ 12 
] mos

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[William A Rowe Jr]

On Wed, May 25, 2016 at 10:11 AM, William A Rowe Jr 
wrote:

>
> So let's try this... would 2.2.x maintainers and PMC folks please answer
> this
> poll -if- you have an intention to help throughout the wind-down of 2.2.x,
> since
> this is all predicated on having committed-committers to participate.
> This isn't
> to say folks refuse to participate after the time period you offer, but
> for how long
> you are personally prepared to participate.  [If you aren't a 2.2.x legacy
> branch
> participant, testing RCs or applying backports, then no response is
> needed.]
>
>  *) I intend to help maintain/test 2.2.x releases over the next [] mos
>
>  *) I intend to backport/review 2.2.x security patches over the next
> [] mos
>

With the holiday weekend here in the US, I'll let the poll run a full week,
and cross-tabulate the results for us this coming Wednesday.

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Yann Ylavic]

On Wed, May 25, 2016 at 5:11 PM, William A Rowe Jr  wrote:
>
*) I intend to help maintain/test 2.2.x releases over the next [18] mos
*) I intend to backport/review 2.2.x security patches over the next [18] mos

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Rainer Jung]

Am 25.05.2016 um 18:11 schrieb William A Rowe Jr:

 *) I intend to help maintain/test 2.2.x releases over the next [12] mos

 *) I intend to backport/review 2.2.x security patches over the next
[18] mos


Rainer

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Gregg Smith]

On 5/25/2016 8:11 AM, William A Rowe Jr wrote:

  *) I intend to help maintain/test 2.2.x releases over the next [_6__] mos
  *) I intend to backport/review 2.2.x security patches over the next [_0__] mos

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Eric Covener]

On Wed, May 25, 2016 at 11:11 AM, William A Rowe Jr  wrote:

*) I intend to help maintain/test 2.2.x releases over the next [18] mos
*) I intend to backport/review 2.2.x security patches over the next [18] mos

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Daniel Ruggeri]

 *) I intend to help maintain/test 2.2.x releases over the next [_12___] mos
 *) I intend to backport/review 2.2.x security patches over the next
[_18___] mos

-- 
Daniel Ruggeri

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Ruediger Pluem]

On 05/25/2016 05:11 PM, William A Rowe Jr wrote:
> On Mon, May 16, 2016 at 5:07 PM, William A Rowe Jr  > wrote:
> 
> On Mon, May 16, 2016 at 1:26 PM, Gregg Smith  > wrote:
> 
> On 5/16/2016 11:03 AM, Eric Covener wrote:
> 
> 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.
> 
> 
> 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 let's try this... would 2.2.x maintainers and PMC folks please answer this
> poll -if- you have an intention to help throughout the wind-down of 2.2.x, 
> since
> this is all predicated on having committed-committers to participate.  This 
> isn't
> to say folks refuse to participate after the time period you offer, but for 
> how long 
> you are personally prepared to participate.  [If you aren't a 2.2.x legacy 
> branch 
> participant, testing RCs or applying backports, then no response is needed.]
> 
  *) I intend to help maintain/test 2.2.x releases over the next [_12___] mos
 *) I intend to backport/review 2.2.x security patches over the next [_12___] 
mos


Regards

Rüdiger

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[William A Rowe Jr]

 *) I intend to help maintain/test 2.2.x releases over the next 12 mos

 *) I intend to backport/review 2.2.x security patches over the next 12 mos

[POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[William A Rowe Jr]

On Mon, May 16, 2016 at 5:07 PM, William A Rowe Jr 
wrote:

> On Mon, May 16, 2016 at 1:26 PM, Gregg Smith  wrote:
>
>> On 5/16/2016 11:03 AM, Eric Covener wrote:
>>
>>> 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.
>>
>
> 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 let's try this... would 2.2.x maintainers and PMC folks please answer
this
poll -if- you have an intention to help throughout the wind-down of 2.2.x,
since
this is all predicated on having committed-committers to participate.  This
isn't
to say folks refuse to participate after the time period you offer, but for
how long
you are personally prepared to participate.  [If you aren't a 2.2.x legacy
branch
participant, testing RCs or applying backports, then no response is needed.]

 *) I intend to help maintain/test 2.2.x releases over the next [] mos

 *) I intend to backport/review 2.2.x security patches over the next []
mos

Re: End of the road of 2.2.x maintenance?

[William A Rowe Jr]

On Mon, May 16, 2016 at 1:26 PM, Gregg Smith  wrote:

> On 5/16/2016 11:03 AM, Eric Covener wrote:
>
>> On Tue, May 10, 2016 at 1: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?
>>>
>> 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?

[Gregg Smith]

On 5/16/2016 11:03 AM, Eric Covener wrote:

On Tue, May 10, 2016 at 1: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?

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?

[Eric Covener]

On Tue, May 10, 2016 at 1: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?

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?

[William A Rowe Jr]

On Wed, May 11, 2016 at 2:31 PM, Mark Blackman  wrote:

>
> On 10 May 2016, at 21:38, 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?
>
> 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?

[Daniel Ruggeri]

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?

[Noel Butler]

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?

[Kurt Newman]

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  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,
> 
> Cheers,
> 
> Bill



smime.p7s
Description: S/MIME cryptographic signature

Re: End of the road of 2.2.x maintenance?

[Mark Blackman]

> On 10 May 2016, at 21:38, 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

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?

[Ruediger Pluem]

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

End of the road of 2.2.x maintenance?

[William A Rowe Jr]

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