Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod From: Sandro Tosi Newsgroups: linux.debian.maint.python,linux.debian.devel.release Subject: Re: Proposal on how to proceed with Python 2 removal from bullseye Date: Wed, 18 Dec 2019 07:10:03 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Wed Dec 18 06:08:54 2019 Old-Return-Path: X-Amavis-Spam-Status: No, score=-4.872 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FREEMAIL_FORGED_FROMDOMAIN=0.218, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SARE_MLH_Stock10=1.66] autolearn=no autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZQthxAwxuF4IauydnFV0fCyBtNV8AODnltJ08Qw138c=; b=N+NEP7oa5XKZPj4cSkYkp3yXDAWDmlYKnGxpWygEHBpoihag/ioOPcHS4um4Eg43Vd MIB5Fz1DmuRJ6bNVUnIHz5E96cy28evdi9dceynhXgfqpwhwRTMsvjb9eMkO35KwQQ6w RZWLwIg4z44VRerg69lkJqoDIozAR13vUxwnrDEtjw90eCdtjiEoEiuxo7OhhASqlLXl UuSAqpArzi5CR/49SQmUZh3Dz2iWYIytgkaORKVbtgQJ3dy1tb5Q7tYvNnho3L3YYNHy ytd0a6w4ilwG8jyoWVik18eVBZt+0H4Kx7bZBNGmcYVIPsMvvAwWqSY4fXGqV0MGOVHQ jTLg== X-Gm-Message-State: APjAAAXdRFzYHylJf3kESLUWL6HM5VCZ+LvaQxMu2Nc7yyikPrmrTceh S/qbA/wdcbZDQHPcPwyFMC5gSEGDCvSc6e/AV4U= X-Google-SMTP-Source: APXvYqwgQoQQZFveqRs6HUH1Vcx1qeOhU28ur2fUri1CHHPO67B6eP6lbhMmOWIegu1jgbGru8ETBuhvrDRU393fv+8= X-Received: by 2002:a05:6214:10cb:: with SMTP id r11mr757879qvs.59.1576649317359; Tue, 17 Dec 2019 22:08:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailing-List: archive/latest/17761 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/CAB4XWXyDCU=RCUtaJF=M0TMtrgthL585_Z6sdEnLWunvfeeciw@mail.gmail.com Approved: robomod@news.nic.it Lines: 57 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Wed, 18 Dec 2019 01:08:11 -0500 X-Original-Message-ID: X-Original-References: <349bb59d7f28ad6c70e567d9939b99f2f924d01a.camel@ondrej.org> <153751f7-2d80-3e4c-feb1-ea8b53767946@debian.org> <5a41fe54-4f24-e3ae-0bd7-d73ce87d7f44@debian.org> Xref: csiph.com linux.debian.maint.python:12158 linux.debian.devel.release:92643 > 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