Date: Mon, 12 Aug 2019 17:27:54 +0200 From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= <martin@waschbuesch.de> To: FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: PHP version retirement Message-ID: <D18D973F-3C2F-44F2-80F5-560E13092E55@waschbuesch.de> In-Reply-To: <CAP7rwcgJ9gReDfECqSLbHKxK5Y86guJSA0pq68pRjwp0eXt%2B8A@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> <C6261FE6-1FAD-44D1-BD06-B33A0CEAAC85@waschbuesch.de> <CAP7rwcg%2B2GeMLz1a%2B-abcjNcA_-mE3B%2Bh5ovC5iU03EKiHbAZg@mail.gmail.com> <2DE6652A-86FF-4F07-9F8D-97E845D41E41@waschbuesch.de> <CAP7rwcgJ9gReDfECqSLbHKxK5Y86guJSA0pq68pRjwp0eXt%2B8A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Adam, > Am 12.08.2019 um 15:29 schrieb Adam Weinberger <adamw@adamw.org>: >=20 > On Mon, Aug 12, 2019 at 1:04 AM Martin Waschb=C3=BCsch = <martin@waschbuesch.de> wrote: >>>>>> Furthermore, the argument that it is more more work to maintain = an abandoned 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 >>>>=20 >>>> I do not understand this. At all. >>>> And I sort of hope I misunderstood you, because it sounds like you = think a maintainer is or may be regarded as someone who can be expected = to provide 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 = people 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, etc. >>=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 FreeBSD, would have the *expectation* of receiving support for those = packages. >> That perception of any kind of entitlement towards volunteers is = wrong, IMHO. >>=20 >> And that is why I answered that part of your message because it is = not (for reasons stated above) a valid argument against having outdated = software in 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. got it. I am glad that we are on the same page here. > 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. Understood. If I wanted to offer my help maintaining a no longer = supported version of php, where would I look to try and identify the = amount of work likely to be involved? Would bugs.freebsd.org be a comprehensive source for such an evaluation? = There are a total of 10 issues in 2018 and 2019 when searching for php = 5.6: = https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=3D__open__&bug_st= atus=3D__closed__&bug_status=3DNew&bug_status=3DOpen&bug_status=3DIn%20Pro= gress&bug_status=3DClosed&bug_status=3DUNCONFIRMED&f0=3DOP&f1=3DOP&f10=3DO= P&f11=3Dproduct&f12=3Dcomponent&f13=3Dalias&f14=3Dshort_desc&f16=3DCP&f17=3D= CP&f2=3Dproduct&f3=3Dcomponent&f4=3Dalias&f5=3Dshort_desc&f7=3DCP&f8=3DCP&= f9=3DOP&j1=3DOR&j10=3DOR&o11=3Dsubstring&o12=3Dsubstring&o13=3Dsubstring&o= 14=3Dsubstring&o15=3Dsubstring&o2=3Dsubstring&o3=3Dsubstring&o4=3Dsubstrin= g&o5=3Dsubstring&o6=3Dsubstring&order=3Dchangeddate%20DESC%2Cpriority%2Cbu= g_severity&query_format=3Dadvanced&v11=3D5.6&v12=3D5.6&v13=3D5.6&v14=3D5.6= &v15=3D5.6&v2=3Dphp&v3=3Dphp&v4=3Dphp&v5=3Dphp&v6=3Dphp I assume there is more work involved (at the very least compiling php = and all its modules with poudriere, for different platforms and / or = versions of FreeBSD, etc.). > 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. Also understood. I took up maintainership of archivers/lz4 a while back = when it was without a maintainer, so I am a little familiar with how = this works. > 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. Would you agree that in the case of software that is no longer = maintained upstream, the support would mostly consist of ensuring the = packages still compile on newer versions of FreeBSD or reacting to = problems arising when dependencies for php change? After all, new = releases or patches from upstream are no longer an issue. > 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. Just as an aside, does that not amount to, well, essentially punishing = others who might be interested in longer availability of ports such as = php after the end of upstream development as a reaction to Franco's = messages? I would understand if you said: "Franco's reasons are not sufficiently = convincing to change the way things are done." But saying: "We won't change the way things are done (even if there were = legitimate reasons) simply because we are fed up with Franco?" I cannot = agree with that. At any rate: My proposal would be a compromise of sorts: If there were people willing to ensure the packages continue to build = without errors on active releases of FreeBSD, could not maintainership = of the most recently EOL php version go over to that group until = something (dependency, change in base system, etc.) prevented the = packages from being successfully built or a specified grace period (6 = months, a year, EOL of next php version, etc.) has expired? Martin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D18D973F-3C2F-44F2-80F5-560E13092E55>