My top-line comment and rational for adjusting things as I have;

We have no desire for users to obtain an unsupported ASF package.
We want users to obtain 2.4.32. We don't want them to patch their
antique flavors, we want them to obtain a supported flavor. We axe
the next-most recent version as soon as our site is updated and
refers to the current release, why not apply the same standard to
any out of date unsupported version minor?

Users running 2.2.x and earlier perhaps want to reference the docs.
We as devs want to reference historical docs (when did that change,
and when did we actually explain that change?!?) But nobody needs
a download of the historical docs, these are simply available over
the internet whenever someone wants to reference or cite them,
until they get around to upgrading.

Bottom line, the website facilitates the user to follow the guidance
we recommend, so anything on that site that assists them in going
against our guidance and better judgement probably doesn't belong.



On Tue, Mar 13, 2018 at 4:32 PM, William A Rowe Jr <> wrote:
> On Tue, Mar 13, 2018 at 3:53 PM, Yann Ylavic <> wrote:
>> On Tue, Mar 13, 2018 at 9:34 PM,  <> wrote:
>>> Author: wrowe
>>> Date: Tue Mar 13 20:34:36 2018
>>> New Revision: 25693
>>> Log:
>>> Drop unsupported files from the distribution site.
>>> These remain available from
>>> Removed:
>> []
>>>     release/httpd/patches/apply_to_2.2.34/
>> Why? First this directory was not empty (IIRC), and I think it could
>> be used to provide security/bug patches for RIP 2.2, maybe some of us
>> still have to make legacy 2.2 work and can share.
>> It looked like the last place (with docs) to worth some/possible updates...
> Here's the issue, with publishing 2.2 patches + security errata on an
> ongoing basis.
> If we are publishing these ongoing as "advised", we are taking the
> responsibility to continue to offer that advise and recommendations
> for any patches we are aware of that mitigate vulnerabilities.
> As we decided a long while back (and reaffirmed in a recent poll)
> that we aren't actually referring back to 2.2.x sources when we
> evaluate and publish advise on CVE-2018-next... well, then it's
> actually irresponsible to publish the corresponding source tarball
> or cumulative patchset on an ongoing basis.
> That said, it wasn't deleted.
> is still available. If we decide not to continue publication of an
> unsupported package, why would the patches/ continue to reside
> where the source package cannot be found?
> As you can see, they are right alongside the current location of
> that package;
> Additional thoughts?
> Cheers,
> Bill

Reply via email to