On Tue, Apr 17, 2018 at 9:47 AM, Graham Leggett <minf...@sharp.fm> wrote:
> On 17 Apr 2018, at 4:41 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>> And everything contributed to 2.4.33 release? All in vain. None of
>> that in this OS distribution, because, code freeze.
>
> I’m not following the “all in vain”.
>
> This patch in v2.4.33 was dine specifically to fix an issue in Xenial, and
> Ubuntu is on the case:
>
> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1750356
Then Ubuntu is distributing neither httpd 2.4.33 nor 2.4.29, as
published by the Apache HTTP Project. This is another example of
cherry picking a miscellany of fixes.
>> We observe the "code freeze" effect (defined by three different
>> distributors) coupled with distributors deep distrust of our releases,
>> so by continuously polluting our version major.minor release with more
>> and more cruft, those users are denied not only the new cruft, but all
>> the bug fixes to the old cruft as well... there's really no other
>> explanation for the users of one of our most common distributions to
>> be locked out of several subversions worth of bugfix corrections.
>
> I’m lost - what problem are you trying to solve?
The problem identified above, distributors falling into the role of
individually, project-by-project, release-by-release managing
versioning of what other modern software projects arbitrage in their
own subversion branches.
The use of the Apache HTTP Server mark itself is predicated on the
software shipped by Apache HTTP Project. So this forking leads to
interesting questions (probably permissible for combinations of code
released at different points by the project).
If a distributor shipped a source package of something called Apache
httpd 2.4.29, which is obviously not .29 but .29+{stuff}, what would
be our reaction?
