[gentoo-dev] Guidelines on Python 2 cleanup

[Michał Górny]

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