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.
regards, Sandro On Thu, Dec 5, 2019 at 6:07 AM Paul Gevers <elb...@debian.org> wrote: > > Hi, > > 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. > > Paul > > PS, my original typed reply below. After having writing it, the idea > above emerged. > > My problem with the current approach is that the way that developers > learn that they (potentially transitively) (build) depend on a Python 2 > package is by the autoremoval message. I don't think that is acceptable > socially in the project. My proposal is to give the maintainers about > those packages a heads up. Via a bug report may be a bit weird in cases, > but in some cases may be the appropriate thing as the package could work > around the (build) dependency. At least adding "affects" helps a tiny > bit and direct e-mails to the maintainers (e.g. via the > <package>@packages.debian.org address will at least give them a heads > up. Even if the RM bug is coming eventually. > > Again, I don't have a problem with Python 2 removal, even at the price > of packages that don't care that their dependency is written in Python. > I do care about proper communication. Using RC severity to trigger > autoremoval for non-leaf packages just yet is not appropriate in the > opinion of the release team. Even though I am well aware of the Python 2 > removal effort I can tell from personal experience (cacti) that > receiving an autoremoval e-mail as the first sign of such a dependency > isn't nice, that's the problem I'm having and that needs solving in my > opinion. > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
