Dear all,
TL;DR: as the subject suggests, proposal included, although not fully
aligned with others.
On 08-12-2019 20:55, Sandro Tosi wrote:
> there seems to be disagreement on how to proceed, so for the time
> being i suspended the severity bump part of the py2removal tracking
> script. let me know when everybody agrees on a solution, and what that
> solution is, and i'll code it and re-enable.
[...]
>> On 03-12-2019 13:19, Matthias Klose wrote:
>>> It's unfortunate that issues for some packages only get attention when the
>>> severity of an issue is raised. Following your proposal means that the
>>> issue is
>>> probably ignored forever, and you don't propose a better way going forward,
>>> just
>>> saying we should stop earlier. I don't think that's the correct choice.
>>> For
>>> now these seem to be single packages, so please could you name those, and
>>> we can
>>> look at those with a priority? That's at least a path that is forward
>>> looking,
>>> or feel free to propose another approach better than your current proposal
>>> for
>>> not getting the attention of maintainers.
>>
>> I guess what I'm asking for could be fulfilled by an announcement to
>> d-d-a with a package list (including via which package(s) they are
>> affected) attached including the standard grouping by DD. And then some
>> time to react.
It has been brought to my attention (thanks ginggs) that I have been
focused too much on the release teams side of the story and on the
maintainer of reverse dependencies side of the story. There are more
facets to the Python 2 removal, my aim of this e-mail is to make it more
balanced.
For full clarity, in my mind the discussion about using RC status to
have the autoremoval process enable the clean up in bullseye was about
the question to the release team if they would support making Python 2
removal bugs RC *from the release teams point of view*. In my reasoning
and responses, I fully forgot the description of serious in the BTS that
explicitly (and in my opinion rightfully) mentions the package maintainer:
"""
is a severe violation of Debian policy (roughly, it violates a "must" or
"required" directive), or, in the package maintainer's or release
manager's opinion, makes the package unsuitable for release.
"""
which is reflected in the release team rc_policy for the last couple of
releases [1].
So, to conclude, within Debian it is considered to be in the full power
of a maintainer to raise the severity of their own package to serious.
Hence, in hindsight I believe the question to the release team was
mostly about Python maintainers marking bugs of *other* maintainers as
RC. I believe that for that last category, the careful approach taken by
the people behind the Python 2 removal and requested in my
communications is warranted.
That said, and keeping in mind that autoremovals only work on non-key
packages [2] and that there is always a social side to invasive changes,
I come with the following *proposal* containing a few items. In all, it
may even speed up the Python 2 removal process:
1) all Python 2 removal bugs *can* be raised to RC level by the
maintainers of the packages they belong to, but:
2) maintainers of non-key packages should carefully consider the
backslash for their transitive reverse (normal, build and test)
dependencies before raising the bug severity level and in my opinion
should hold off doing that if there are many that need adaption for the
Python 2 support removal. To be absolutely clear of my intent, if there
is only a *very* limited set that needs adaption but they have a large
set of reverse dependencies that is not what I mean here. The
maintainers of the large set of reverse dependencies have a joint
incentive to fix the issue if the maintainer of the to-be-adapted
package(s) doesn't step up to fix the situation.
3) packages with unfixed reverse (normal, build or test) dependencies,
that want to drop Python 2 support should first make sure their unfixed
reverse dependencies have RC bugs themselves (but please take the
consideration of 2 into account), stating at least something like
"source package $foo is soon going to remove the binary $bar package on
which the $baz package (build) depends, please fix that".
To avoid problems with bug fixes that need to migrate to testing soon,
please don't upload the Python 2 support drop immediately, but wait
until either the reverse dependencies are fixed or the date for the
autoremoval is near.
4) leaf packages (i.e. without normal, build or test reverse
dependencies) that need to be adapted themselves for the Python 2
removal can be marked as RC.
5) Please continue to use the approach used so far as well, but please
also add checks on build dependencies.
Paul
[1] https://release.debian.org/buster/rc_policy.txt
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
signature.asc
Description: OpenPGP digital signature
