From owner-freebsd-ports@freebsd.org Mon Aug 12 14:13:22 2019 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40C2CB4D36 for ; Mon, 12 Aug 2019 14:13:22 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 466d9Y29SWz4PXb for ; Mon, 12 Aug 2019 14:13:21 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [100.100.187.97] (ip-109-40-130-17.web.vodafone.de [109.40.130.17]) by host64.shmhost.net (Postfix) with ESMTPSA id 466d9W0S7PzBrQM; Mon, 12 Aug 2019 16:13:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: PHP version retirement From: Franco Fichtner X-Mailer: iPhone Mail (16G77) In-Reply-To: Date: Mon, 12 Aug 2019 17:13:16 +0300 Cc: =?utf-8?Q?Martin_Waschb=C3=BCsch?= , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: <705E8D0E-F558-4ABE-B771-1BB273397766@lastsummer.de> References: <64faf143-bae3-378c-3ee2-b196c2ea4111@astart.com> <16731AF5-68E9-4E41-8D21-CF5917BE32A4@waschbuesch.de> <20190810231216.GA23293@lyxys.ka.sub.org> <2DE6652A-86FF-4F07-9F8D-97E845D41E41@waschbuesch.de> To: Adam Weinberger X-Virus-Scanned: clamav-milter 0.100.3 at host64.shmhost.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 466d9Y29SWz4PXb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of franco@lastsummer.de has no SPF policy when checking 213.239.241.64) smtp.mailfrom=franco@lastsummer.de X-Spamd-Result: default: False [-0.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.130.40.109.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; IP_SCORE(-0.20)[ip: (0.88), ipnet: 213.239.192.0/18(-0.05), asn: 24940(-1.83), country: DE(-0.01)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lastsummer.de]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.66)[-0.657,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.32)[-0.324,0]; RCVD_IN_DNSWL_NONE(0.00)[64.241.239.213.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.82)[-0.820,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 14:13:22 -0000 > On 12. Aug 2019, at 16:29, Adam Weinberger wrote: >=20 > On Mon, Aug 12, 2019 at 1:04 AM Martin Waschb=C3=BCsch wrote: >>>>>> Furthermore, the argument that it is more more work to maintain an ab= andoned version is silly because it=E2=80=99s more work to delete a port tha= t 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 >>>>=20 >>>> I do not understand this. At all. >>>> And I sort of hope I misunderstood you, because it sounds like you thin= k a maintainer is or may be regarded as someone who can be expected to provi= de product support of some kind? >>>> I find that notion worrying to say the least. >>>=20 >>> If you believe that handling updates, analyzing submitted and upstream >>> patches and development, and answering a bevy of questions for every >>> major update is effortless, then you drastically underestimate the >>> amount of work that goes into the ports tree. >>=20 >> You completely misunderstand me. >> I know there is a lot of effort going into this. I disagree only in that I= do not believe there should be any expectations towards maintainers. >> It is voluntary work. Spare time, etc. I am grateful for the effort peopl= e put into this, but I strongly believe no one should act towards volunteers= with any expectations as to what they should do, how much time they spend, e= tc. >>=20 >> So, I find it wrong to say, as I understood you, to remove a package from= the ports tree because otherwise others people, for instance users of FreeB= SD, would have the *expectation* of receiving support for those packages. >> That perception of any kind of entitlement towards volunteers is wrong, I= MHO. >>=20 >> And that is why I answered that part of your message because it is not (f= or reasons stated above) a valid argument against having outdated software i= n the ports tree. >=20 > Ah! You're right, I did completely misunderstand you. >=20 > You're correct that we don't provide any semblance of support for the > upstream software. Absolutely, and under no circumstances should > anyone have to. >=20 > I'm referring to support of the port itself. Maintainership requires > responding to private emails asking for help; evaluating, testing, and > approving submitted patches; responding to PRs about changes or fixes > or poor behaviour (90% of the time related to portmaster); responding > to error reports; and so on. >=20 > We do expect those things from maintainers, because those are what are > required to keep the ports tree running. And we actively drop > maintainership from ports where maintainers routinely ignore those > responsibilities, regardless of whether they have a commit bit. >=20 > As decke noted, maintainership of a small port with relatively low > deployment is pretty smooth (and don't get me wrong, they're as or > more important than the big packages). But a huge and complex > framework like php is a massive undertaking, with a near-constant > barrage of complex patches that require highly complex testing > strategies, and thousands of dependent ports to worry about for every > change. Sure, if you feel like that is so there is no need to argue about it. I stil= l feel the latent drift of =E2=80=9Cphp is high profile and low profile is e= asy=E2=80=9D like a sneaky way out of a fruitful discussion ignoring the req= uest made by users: don=E2=80=99t kill software on tight schedules if there i= s no technical need for it. Unless you want to state a valid technical reason. For PHP 5.6 removal espec= ially one has to assume that general arguments are merely made up here to fi= t the general lack of disagreement on the grace period issue. That=E2=80=99s fine and easier to say you don=E2=80=99t want to do it vs. it= cannot be done. :) > I suggested that it might be possible for stale languages to remain in > the tree, as long as the above support wasn't required or expected. > But, honestly, Franco's response mocking the offer made my desire to > help him somewhere at or below zero, and has pretty much ensured that > nobody else in portmgr is going to be eager to get skin in the game. I=E2=80=98m merely pointing out you=E2=80=98re unwilling to do it and your o= ffer was impractical for users running any PHP extension but you were not st= raight forward in your answer previously. This segment at least makes it cle= ar so thank you for being frank about it. To sum it up there is no desire by= maintainers to do what users requested here so yay for that conclusion at l= east. Cheers, Franco