Date: Mon, 12 Aug 2019 09:20:35 +0300 From: Franco Fichtner <franco@lastsummer.de> To: Adam Weinberger <adamw@adamw.org> Cc: =?utf-8?Q?Martin_Waschb=C3=BCsch?= <martin@waschbuesch.de>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: PHP version retirement Message-ID: <5B284DDA-69FB-4936-B3CD-B051DB936F7E@lastsummer.de> In-Reply-To: <CAP7rwcjR8SYmeJJe9KrmZRJj7qQpnjQ6N8kaqrdpDSDB4cFH6g@mail.gmail.com> References: <CF1F28D6-1072-4BE6-B124-A97DE43FA4E6@waschbuesch.de> <64faf143-bae3-378c-3ee2-b196c2ea4111@astart.com> <16731AF5-68E9-4E41-8D21-CF5917BE32A4@waschbuesch.de> <20190810231216.GA23293@lyxys.ka.sub.org> <CD11C7D8-DC57-4402-848C-06BBAD220D8B@waschbuesch.de> <D7D5D66C-AD53-4F2E-95E5-F0131DBC82AA@lastsummer.de> <CAP7rwcjR8SYmeJJe9KrmZRJj7qQpnjQ6N8kaqrdpDSDB4cFH6g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 12. Aug 2019, at 00:22, Adam Weinberger <adamw@adamw.org> wrote: >=20 >> On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner <franco@lastsummer.de> wr= ote: >>=20 >> Quarterly is essentially useless if the decision is to immediately axe a d= eprecated release. 3 months are nothing in production environments, if you g= et 3 months (1,5 months mean) at all and also all other updates and security= relevant bug fixes in the same quarterly that you desperately need. >>=20 >> Yeah, we know that won=E2=80=99t happen so please don=E2=80=99t suggest i= t. >>=20 >> That deprecation policy is nice and well all by itself except when it wre= aks havoc over the ports infrastructure like in the case of PHP version supp= ort where numerous ports are immediately unavailable and incompatible with u= pgrades. >>=20 >> Furthermore, the argument that it is more more work to maintain an abando= ned version is silly because it=E2=80=99s more work to delete a port that to= just keep it in the tree for a while longer. >=20 > That last part isn't correct. The work of deleting the ports is > largely automated and simple, and it will always happen eventually. > The work involved is in supporting unsupported versions. Our php team > is spread very thin, and they simply cannot support php versions > outside of upstream development. There are no resources to backport > fixes that may or may not be designed to work with older versions I don=E2=80=99t believe this is anywhere near true for two reasons: FreeBSD p= orts does not add as much maintainers as it says it desperately needs so you= are creating a scarce environment to base your =E2=80=9Etoo much work=E2=80= =9C argument on. The other part is having handled a ports fork myself since 2= 015 the work to keep a port where it is is low at its worst. >> That =E2=80=9Ewhile=E2=80=9C is debatable, but it=E2=80=99s neither indef= initely nor immediately. The people responsible for FreeBSD ports and packag= es would be wise to enrich their policies with a more graceful way of dealin= g with legacy software, especially if it relates to more than a handful of p= orts in a single deprecation decision. >>=20 >> TL;DR: don=E2=80=99t remove PHP ports prematurely and you=E2=80=99ll have= less work reading mails like these. >=20 > Part of the contract in providing packages includes providing support > for them. Other OSes provide packages for software that they can never > support, and there are definitely consequences for that paradigm. This > is doubly true for PHP, which is extremely common and for which > security fixes can be vitally important. Well, you are arguing against a grace period for obsolete software which is q= uite pointless because the software is not bad per se. It will be eventually= and it should be removed and nobody argued against that. In the case of PHP 5.6 a clear error of judgement was made based on a reason= able decision at the time. It should give enough incentive to not let this h= appen again so quickly and try to learn from how it negatively impacts users= . I=E2=80=98m going to reiterate because nobody acknowledges the obvious: 1,5 m= onths mean of a grace period in quarterly is productions worst enemy, not to= mention when you run HEAD. > I've been thinking about this a lot lately (I used to be hardline > against it), but at this point I am not fundamentally opposed to the > idea of providing old versions of major languages and interpreters, as > long as (a) they cannot be specified by DEFAULT_VERSIONS, (b) nothing > can ever depend on them, and (c) it is clear that they are provided > without support and at your own peril. That makes no sense for PHP ports which are part of the picture here. But yo= u probably know that. :) Cheers, Franco
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B284DDA-69FB-4936-B3CD-B051DB936F7E>