PHP version retirement

Mon Aug 12 15:28:03 UTC 2019

Hi Adam,

> Am 12.08.2019 um 15:29 schrieb Adam Weinberger <adamw at adamw.org>:
> 
> On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch <martin at waschbuesch.de> wrote:
>>>>>> Furthermore, the argument that it is more more work to maintain an abandoned version is silly because it’s more work to delete a port that to just keep it in the tree for a while longer.
>>>>> 
>>>>> 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 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.
>>> 
>>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
> 
> Ah! You're right, I did completely misunderstand you.
> 
> 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=__open__&bug_status=__closed__&bug_status=New&bug_status=Open&bug_status=In%20Progress&bug_status=Closed&bug_status=UNCONFIRMED&f0=OP&f1=OP&f10=OP&f11=product&f12=component&f13=alias&f14=short_desc&f16=CP&f17=CP&f2=product&f3=component&f4=alias&f5=short_desc&f7=CP&f8=CP&f9=OP&j1=OR&j10=OR&o11=substring&o12=substring&o13=substring&o14=substring&o15=substring&o2=substring&o3=substring&o4=substring&o5=substring&o6=substring&order=changeddate%20DESC%2Cpriority%2Cbug_severity&query_format=advanced&v11=5.6&v12=5.6&v13=5.6&v14=5.6&v15=5.6&v2=php&v3=php&v4=php&v5=php&v6=php

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