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 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
> @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
