Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #11995 > unrolled thread

Severity bump script

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Severity bump script Ondrej Novy <novy@ondrej.org> - 2019-11-11 07:50 +0100
    Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-11-11 16:50 +0100
    Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-11-15 01:20 +0100
      Re: Severity bump script Dmitry Shachnev <mitya57@debian.org> - 2019-11-15 19:50 +0100
        Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-11-16 04:10 +0100
      Re: Severity bump script Ondrej Novy <novy@ondrej.org> - 2019-11-22 09:40 +0100
        Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-11-22 22:30 +0100
          Re: Severity bump script Ondrej Novy <novy@ondrej.org> - 2019-11-27 20:40 +0100
            Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-11-28 04:20 +0100
              Re: Severity bump script Ondrej Novy <novy@ondrej.org> - 2019-11-28 13:40 +0100
                Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-11-28 19:10 +0100
                  Re: Severity bump script Ondrej Novy <novy@ondrej.org> - 2019-11-28 21:00 +0100
    Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-12-01 22:50 +0100
      Re: Severity bump script Paul Gevers <elbrus@debian.org> - 2019-12-02 20:30 +0100
        Re: Severity bump script Paul Gevers <elbrus@debian.org> - 2019-12-02 20:40 +0100
          Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-12-02 22:20 +0100
            Re: Severity bump script Paul Gevers <elbrus@debian.org> - 2019-12-02 22:30 +0100
              Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-12-02 22:50 +0100
              Re: Severity bump script Mattia Rizzolo <mattia@debian.org> - 2019-12-02 23:40 +0100
          Re: Severity bump script Ondrej Novy <novy@ondrej.org> - 2019-12-03 10:40 +0100
        Re: Severity bump script Ondrej Novy <novy@ondrej.org> - 2019-12-02 21:00 +0100
        Re: Severity bump script Matthias Klose <doko@debian.org> - 2019-12-03 13:30 +0100
          Re: Severity bump script Paul Gevers <elbrus@debian.org> - 2019-12-05 12:10 +0100
            Re: Severity bump script Sandro Tosi <morph@debian.org> - 2019-12-08 21:00 +0100
              Proposal on how to proceed with Python 2 removal from bullseye Paul Gevers <elbrus@debian.org> - 2019-12-14 21:00 +0100
                Re: Proposal on how to proceed with Python 2 removal from bullseye Sandro Tosi <morph@debian.org> - 2019-12-18 07:10 +0100
                  Re: Proposal on how to proceed with Python 2 removal from bullseye Simon McVittie <smcv@debian.org> - 2019-12-22 12:00 +0100
                    Re: Proposal on how to proceed with Python 2 removal from bullseye Sandro Tosi <morph@debian.org> - 2020-01-07 00:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#12089

[Multipart message — attachments visible in raw view] — view raw

Hi,

po 2. 12. 2019 v 20:28 odesílatel Paul Gevers <elbrus@debian.org> napsal:

> I understand the drive to push for Python 2 removal and sympathize with
> it. The issue I had yesterday with the process is that "leaf" was
> wrongly defined, it was looking at Depends, instead of also including
> Build-Depends.
>

huh? We are not bumping any "blocked" bugs.
Depends/Build-Depends/Recommends/autopkgtests usage marks bug as blocked.
Any example of "wrong definition" please?

-- 
Best regards
 Ondřej Nový

[toc] | [prev] | [next] | [standalone]

#12096

On 02.12.19 20:28, Paul Gevers wrote:
> Hi all,
> 
> On 01-12-2019 22:45, Sandro Tosi wrote:
>> Paul, this is the thread i was talking about.
>>
>> you were copied in the original email:
>> https://lists.debian.org/debian-python/2019/10/msg00098.html
>>
>> if there is something the RT wants to discuss about this effort,
>> please do so here, not directly to me (i may be the mail address
>> sending those control commands, but the decision was taken here).
> 
> I understand the drive to push for Python 2 removal and sympathize with
> it. The issue I had yesterday with the process is that "leaf" was
> wrongly defined, it was looking at Depends, instead of also including
> Build-Depends.

that should be fixed.

> I don't want to stand in the way of Python 2 removal, but as I said
> before, pulling packages out from underneath maintainers isn't pretty so
> needs to be done with proper notifications and care. An RC bug to ones
> own package is acceptable in my opinion as it is a clear discussion
> forum, and can be (temporarily) down-graded while the discussion is
> ongoing. Being notified about some other package that I not even need
> directly but is going to pull "my" package out of testing isn't a nice
> experience and should be avoided. Yes, that slows down the process, but
> there are people, emotions and all those irrational things involved.

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.

Matthias

PS: There's a RC issue for creduce now, not caused by the package itself, should
I downgrade it?

[toc] | [prev] | [next] | [standalone]

#12110

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#12128

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

[toc] | [prev] | [next] | [standalone]

#12151 — Proposal on how to proceed with Python 2 removal from bullseye

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#12158 — Re: Proposal on how to proceed with Python 2 removal from bullseye

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

i've modified the py2removal script as follow:

- extended the "real rdeps" concept as follow: while processing pkgA,
pkgB is a "real" reverse dependency of pkgA iff
-- pkgB is from another source package than pkgA (so python-foo-dbg
will not longer be marked as a rdep of python-foo, as ideally they
will get removed at the same time, as part of the same src:foo pkg)
-- if the pkgB is in testing (there are several packages in unstable
broken beyond repair, so even if we remove pkgA, it will still remain
broken but we can make progress on the py2removal front)
- added the check "real rdeps" == 0 both for modules and applications
(previously it was only for modules).

a test run shows only 3 additional severity bumps will happen when
re-enable, which i plan on doing with the next run (in 8~10 hours).

let me know if this makes sense or additional changes are required.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#12166 — Re: Proposal on how to proceed with Python 2 removal from bullseye

On Wed, 18 Dec 2019 at 01:08:11 -0500, Sandro Tosi wrote:
> let me know if this makes sense or additional changes are required.

#942941 in src:dbus-python was bumped to serious because:
> python-dbus-tests is a module and has 0 external rdeps or not in testing

Please could you give python-dbus-tests or *-tests an exception to the
RC severity bumps, or only bump the severity if *every* Python 2 binary
package in a source package is eligible for removal, or something?
python-dbus still has a significant number of rdeps, and I don't want to
support python-dbus without keeping its automated tests available.

For now I've downgraded it back to normal.

Thanks,
    smcv

[toc] | [prev] | [next] | [standalone]

#12193 — Re: Proposal on how to proceed with Python 2 removal from bullseye

On Sun, Dec 22, 2019 at 5:58 AM Simon McVittie <smcv@debian.org> wrote:
>
> On Wed, 18 Dec 2019 at 01:08:11 -0500, Sandro Tosi wrote:
> > let me know if this makes sense or additional changes are required.
>
> #942941 in src:dbus-python was bumped to serious because:
> > python-dbus-tests is a module and has 0 external rdeps or not in testing
>
> Please could you give python-dbus-tests or *-tests an exception to the
> RC severity bumps, or only bump the severity if *every* Python 2 binary
> package in a source package is eligible for removal, or something?
> python-dbus still has a significant number of rdeps, and I don't want to
> support python-dbus without keeping its automated tests available.

i just implement what asked here, with also a "rollback" functionality
that will downgrade any RC bug for a source with not-leaf packages.
there's a chance some bugs which severity was raised by hand (f.e.
because a dependency package was removed) will get reverted to normal,
we'll see how it goes. the change will go live in a few minutes.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.maint.python

csiph-web