Hello, everyone. There has been some unrest wrt Python 2 removal lately. To put things back in order, I've spent a considerable time filing bugs for all the remaining packages yesterday (some of them turned out to be false positives, sorry) and I'd like to issue some official guidelines to avoid misunderstandings.
The official deadline for Python 2 in Gentoo is 2021-01-01. This means that up to this date, all packages have to be ported to Python 3, with new versions stable and the last old versions ready to be cleaned up. All unported packages will be last rited with 30 day removal period and no possible extension. I would really like to avoid extending the deadline. That is, unless the big G. or the big M. forces us to. Apparently they're too busy inventing new programming languages to port their scripts. However, we shouldn't wait till the last minute. It makes sense to wait for packages that are high-profile and/or have good chances of actually being ported. It doesn't make sense to delay removing some obscure package that hasn't seen any activity in 10 years. The whole point is that we last rite packages in smaller batches that make it easier to deal with, and that we last rite them early to give more time for users to react. It would really suck if we did a 250-package last rites on January 1st. Now, to the guidelines: 1. Normally, last rites apply only to packages that *unconditionally* need Python. Please *do not* last rite packages if it is sufficient to mask USE=python or alike. 1a. Masking or removing conditional Python support is not need immediately necessary; however, it may be desirable to do it early to give users more time to complain, and to unblock dependencies if there are any. 1b. A corner case here are packages requiring Python for tests. Restricting tests suck. 1c. In case of some unmaintained packages, where other treecleaning conditions apply, it may be desirable to last rite anyway. 2. Give people a chance to react. Last rite only if there is no reply to the relevant bug for, say, 30 days. 2a. If maintainers point out that the work is underway, it's fine to wait. 2b. But if the work has stopped progressing for a long time now and it is unlikely that it will be completed before the deadline, it may be better to stop waiting and warn the users. 3. Do not last rite reverse dependencies without warning. If you notice some last rite candidate is blocked, please *at the very least* CC maintainers of revdeps to give them notice that their packages are affected. Filing extra bugs is even better. 3a. I suppose extra bugs shouldn't be necessary if revdeps belong to the same family of packages and have the same maintainer (i.e. you can clearly guess they need to go as well). 4. Leave high-profile and/or likely-to-be-ported packages for later. At least right now we have enough obscure and dead packages to last rite first. 4a. That doesn't mean wait with them forever. It would be nice not to last rite all high-profile packages in one go. 5. Please *verify* everything before proceeding. As I've mentioned, some bugs might be false positives. Some packages may be fixed without closing the bug. 5a. Also note that some packages have || deps that show up in rdep reports but don't justify last riting reverse dependencies. 5b. Please file stabilization bugs (but do not CC arches without approval) or ping maintainers wrt cleanup whenever appropriate. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part