Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
On Sun, Oct 13, 2019 at 11:41:38PM -0400, Nicholas D Steeves wrote:
> Hi Thomas and Python Team,
>
> Thomas Goirand <zigo@debian.org> writes:
>
> > For example, today I looked into removing Python 2 from python-cogent.
> > Running sixer on all files lead to a huge log of problems to solve by
> > hand. There's no upstream support for Python 3 on that one.
> >
> > For this kind of package, I see no way out except:
> > - Upstream works on Python 3 support
> > - Someone in Debian makes the effort
> >
> > But in both cases, it's going to take a very long time. Do we really
> > want to get stuck on these packages for like forever, or would it feel
> > ok to raise the severity to serious, so that the package gets
> > auto-removed and then we can work on removing Python 2 from its
> > dependencies?
>
> It seems to me that a fair and conservative solution is to send an
> announcement once a month that all Python 2 packages will have an RC bug
> filed against them on 1 January 2020. I work on the Calibre package,
> and depend on it for my daily work. I do not believe that its reverse
> deps should be removed before 1 Jan 2020.
That doesn't mean that the rest of Debian should be held up by your personal usage.
It is trivial for you to arrange a local build and even a local repo to meet your
local needs. The package does not need to be in the archive blocking other people's
work just because you personally need it. Calibre is not a special case. If that
logic was applied everywhere, nothing would ever get done. It's a shame, for me,
that lava and associated packages have already been removed from testing as I
used to work on those. I changed jobs, changed workspace and no longer have
time to get the remaining (small) issues fixed to keep the packages in testing
and the remaining team have made their own choices on how to publish new releases
due to the reduced team size.
I could make the same argument as you about tftpy but I've put my personal situation
into the bug report and if I don't get time to fix it, then tftpy will need to
be removed from testing.
There have been enough conservative notifications and announcements about Python2
from every organisation with even the most remote connection to Python.
I think all Python2 bugs should be escalated to RC to have automatic removal from
unstable and testing at the earliest opportunity.
As of now, calibre is not of sufficient quality to be part of a Debian release
and until it drops all Python2 requirements, it must be considered RC buggy.
Accept that there has already been enough time for announcements, put the
current status - as you see it - into the bug report and raise the severity
to RC yourself. That's my recommendation for Calibre and all the other
leaf packages with any dependency on Python2.
There has already been enough time for delay.
> As far as the maximum number of announcements, how about: the first
> announcement ASAP, the second one 1 Nov, then 1 Dec. Lets CC this
> announcement to devel, -python, -med, and any other teams with a
> significant number of Python packages.
>
> The issue is similar to global warming. People will hide their head in
> the sand singing "nah nah nah, it's not real, I don't have to deal with
> it" until a tipping point occurs.
That tipping point has already been reached. The Python2 removal transition
is in full flow and has been since DebConf. No more delays.
>
> Honestly part of me wonders if RedHat/IBM is going to maintain Python 2,
> like they did with Java.
>
> https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support
>
> Barring that hypothetical possibility, I still think the right thing to
> do is file RC bugs the 1 of January. What happens then? My guess is
> upstreams start containerising their py2 software and someone will write
> a helper script like py2-zombie-flatpack.
>
>
> Cheers,
> Nicholas
Reply to: