Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <95C74A6C-BD2D-4C7B-AF0C-DA4BC9E68494@exonetric.com>
References: <CACsi252LR20peBLV2TZVLYDHXm+k_Y9Ph1XiQb_+UqCFE--kgg@mail.gmail.com>
	<95C74A6C-BD2D-4C7B-AF0C-DA4BC9E68494@exonetric.com>
Date: Mon, 16 May 2016 11:43:00 -0500
Message-ID: <CACsi251z1-ycJv025H2+MsuK4C+RSVURFwngf+AQfkOQmdvgjw@mail.gmail.com>
Subject: Re: End of the road of 2.2.x maintenance?
From: William A Rowe Jr <wrowe@rowe-clan.net>
To: Mark Blackman <mark@exonetric.com>
Cc: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a113f3d26433c490532f85186
archived-at: Mon, 16 May 2016 16:43:07 -0000

--001a113f3d26433c490532f85186
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=E2=80=99s policies very closely, I would prefer to delay thi=
s 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 Apach=
e
> 2.4 to meet internal audit policies. I would propose the 12 month countdo=
wn
> 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=E2=80=99s 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

--001a113f3d26433c490532f85186
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 11, 2016 at 2:31 PM, Mark Blackman <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mark@exonetric.com" target=3D"_blank">mark@exonetric.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><span c=
lass=3D""><br><div><blockquote type=3D"cite"><div>On 10 May 2016, at 21:38,=
 William A Rowe Jr &lt;<a href=3D"mailto:wrowe@rowe-clan.net" target=3D"_bl=
ank">wrowe@rowe-clan.net</a>&gt; wrote:</div><div><div dir=3D"ltr"><div><di=
v style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">Are =
we ready to start the 12 month countdown as of the next/final bug</div><div=
 style=3D"font-size:12.8px">fix release of 2.2, and highlight this in both =
the 2.2 and 2.4 announce</div><div style=3D"font-size:12.8px">broadcasts?</=
div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8p=
x"><span style=3D"font-size:12.8px">Feedback desired</span><br></div></div>=
</div></div></blockquote></div></span><div>As a big consumer of Apache 2.2 =
in my day job, where we are obliged to track Apache=E2=80=99s policies very=
 closely, I would prefer to delay this a bit. When Apache announces the for=
mal 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 (a=
s a consumer).</div></div></blockquote><div><br></div><div><div>An underlyi=
ng issue from my own perspective is that OpenSSL 1.0.1 support ends this ye=
ar on December 31st. If there were ever a critical time to update a deploym=
ent stack from end-to-end, the termination of support for the highest-risk =
component would be the time to do so.</div><div><br></div></div><div>From a=
n operational perspective, the historical trend has been a 3 year rolling d=
eprecation of physical commodity hardware systems (although not for big iro=
n). It seems within the scope of modern cloud and virtualized deployments, =
that window may be growing =C2=A0shorter - with many apps provisioned on th=
eir own discrete client environments.</div><div><br></div><div>The larger i=
ssue from our perspective, as an open-source collaboration - not as a comme=
rcial 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 r=
eleased 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 miti=
gation in terms of support, or assume the risk of supporting the source cod=
e themselves (it is open source, when it breaks we all get to keep all of t=
he pieces and fix them as we like.)=C2=A0<br></div><div><br></div><div>This=
 isn&#39;t really an appropriate role for ASF projects and volunteers. The =
2.4 release a radically different situation than Gnome 3, for example, whic=
h led to a split of opinion and dedicated communities interested in continu=
ing the legacy of Gnome 2. The migration path from 2.2 to 2.4 is not painle=
ss, but is really not complex or unfamiliar. Modules are included to ease t=
he transition, particularly the transition of auth schemas.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><div></div><d=
iv>What=E2=80=99s the cost of maintaining (but maybe not updating) Apache 2=
.2?</div></div></blockquote><div><br></div><div>Finding the volunteers amon=
g 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 advanc=
e the development trunk.</div><div><br></div><div>Already, a rather large m=
ajority of our committers have abandoned the 2.2 maintenance branch and foc=
us their attentions on trunk (2.6/3.0 future release) and the 2.4 maintenan=
ce branch. So this question is largely directed to the dedicated minority o=
f committers who have continued to service this branch throughout its 10 ye=
ars.</div><div><br></div><div>If there are 3 clear votes against moving tow=
ard EOL at this time from our PMC, this poll would fail (there is a big eno=
ugh 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 EO=
L by default.</div><div><br></div><div>Note that our choice to end ASF deve=
lopment 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&#39;d suggested that we may continue to collect sec=
urity patches to the final 2.2.x release, as we have several distributors r=
epresented 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 wou=
ld simply elect not to craft a &quot;release&quot; of that software followi=
ng our EOL consensus date. Two vendor-supported examples, RHEL 6 still ship=
s 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&#=
39;s a byproduct of their decisions, not ASF decisions.</div><div><br></div=
><div>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&#39;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.</div><div><br></div><div>Yours,</div><div><br></=
div><div>Bill</div><div><br></div><div><br></div></div></div></div>

--001a113f3d26433c490532f85186--