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. 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. 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
Attachment:
signature.asc
Description: PGP signature