On 27. 05. 22 14:34, Neal Gompa wrote:
While unfortunate, I think it makes sense to retire Python 3.7 when
Debian 10 goes EOL.
I don't understand why do you consider this unfortunate.
I think the larger question is how do we write
down a multi-Python maintenance policy to codify this?
It has been so far implicitly (but indeed not written) somehow like this:
"We keep a Python version in Fedora as long as:
1) A "significant enough" platform that our users could be deploying into runs
that Python version. That has always been at least RHEL, Debian and Ubuntu LTS.
2) It is bearable for the maintainers."
1 means we drop it when it's no longer useful.
2 means we drop when we cannot longer make it work with the current resources.
assumption here is that we're going to be able to leverage security
support work in other distributions to keep other Python runtimes
alive, but I don't think we've got that written down anywhere.
At least for RHEL, we still use Fedora as upstream for our patches. So as long
as a Python is supported in RHEL, we would (in most cases) try to fix Fedora
together with RHEL.
For upstream EOLed Pythons that are not in RHEL but are supported in other
distros (e.g. Python 3.7 will be supported in Debian for ~1 additional year
after upstream EOL, but is not included in RHEL), we don't know yet (it never
happened until now).
Moreover, we don't have anything written down for where to
and source security fixes across distributions for multi-Python
(assuming that's a goal here).
Not necessarily my goal, but a nice goal nevertheless.
If we're not doing any of that, then I'm not sure why other
distributions matter for our multi-Python support beyond just making
it easier to target those distributions. And if that's true, then we
should have that codified too.
Making it easier to use Fedora when you target those distributions was my
primary goal here.