Hi Thomas and Python Team,

Thomas Goirand <z...@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.

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.

Honestly part of me wonders if RedHat/IBM is going to maintain Python 2,
like they did with Java.


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.


Attachment: signature.asc
Description: PGP signature

Reply via email to