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