On Mon, Feb 1, 2021, at 9:18 PM, Christian Walde wrote:
> Before you can "drop support" for something, we must first actually define what "support" means and define it, as well as policies and guidelines for dropping support, and document them.
>
> https://github.com/Perl/perl5/issues/18243
True! I read that issue, had a little bit of commentary, talked to Neil and Sawyer, and I think we should add some language to this, roughly saying:
* some configurations have first-class support: we test them before release and if we see they stopped passing tests, we won't make a stable release (at least without seriously extenuating circumstances)
* some configurations have second-class support: we believe they work, and if we get a report of new breakage, we'll look at how it can be fixed, but we don't guarantee anything
* some configurations are on the chopping block because we believe they present an ongoing burden but aren't in use or likely to come into use
The great majority of configurations are (I think) in the second class. There is surely some variability in the amount of work or chance of success for some configurations in that category. In some cases, it will be easy or compelling: bisection will make clear what caused the problem, it will be recent and easy to test a fix. In others, it will be nightmarish: the configuration is not known to have ever worked, the reasons for failure are unclear, nobody but the complainant has access to a test machine, &c. Still, if we're not planning to remove the code to allow the configuration, it's in that category.
Then the question is how we classify builds, and how you move between categories.
To become a configuration with first-class support, first there must be an active smoker on that platform. Then, there needs to be general agreement among the committers that the configuration is important enough to block stable releases when known broken. My guess: we put a list of these somewhere (perlport?) and pull requests to amend the list are reviewed and applied based on what seems realistic.
The more complex question is when to put something on the chopping block. I think the answer has to be "when it's getting in the way and bearing no weight." For example, Windows Vista came up recently. Is anyone running Vista plus Perl 5.32? Is maintaining compatibility with Vista making the Windows code for Win10 harder to maintain? If so, we should explain this and prepare to remove support for Vista.
What does that mean? I think this may need to be resolved on a case by case basis. For example, last year we eliminated supporting code for Symbian, because we felt certain it could not have built for years. On the other hand, maybe perl on Vista is being built here and there. Or maybe the question will not be about no longer building, but no longer running properly. I think that we'll want to have two basic go-to policies here:
* this thing has not worked in ages, nobody complained, and we are just going to remove the illusion that it might work
* this thing worked, but we think it is no longer seeing any use, so we will issue a big complaint when building for it and give it one full release cycle for anybody to show up with a great reason why it should be spared
I am happy to write this up in the pod. Thoughts?
--
rjbs