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

Groups > linux.debian.maint.python > #12158

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

Cross-posted to 2 groups.

Show all headers | View raw

> 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

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web