Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
On Mon, Oct 14, 2019 at 10:14 PM Thomas Goirand <zigo@debian.org> wrote:
>
> On 10/14/19 3:54 PM, Sandro Tosi wrote:
> >>> But in both cases, it's going to take a very long time. Do we really
> >>> want to get stuck on these packages for like forever, or would it feel
> >>> ok to raise the severity to serious, so that the package gets
> >>> auto-removed and then we can work on removing Python 2 from its
> >>> dependencies?
> >>
> >> for me it's perfectly fine to rise severity to serious of all leaf packages with py2remove bug as soon as possible. And let's do it "automatically" everytime any package gets leaf state.
> >
> > i think it's a bit premature to raise severity to RC (we should also
> > check with the release team): these bugs have been opened since just 2
> > months and a half, and the development cycle for bullseye started not
> > longer before. there's still a lot of time.
>
> It's not as if it has been 10 years we know about this transition, right? :)
definitely 10 years ago we did not know python2 upstream maintenance
would terminate on jan 1, 2020; nor that debian will push to remove
python2 from bullseye.
> How many months do you want to add? Do you seriously think it's going to
> significantly change something about an eventual situation where
> upstream hasn't done the work? If upstream did the work, then what's
> blocking us?
>
> If we see a package where upstream has Py3 support, we don't need to
> raise the severity, we can just do the work instead.
you are trying to generalize the situation of ~3000 packages, it just
doesnt work; every situation is different. There are cases where
upstream release a py3k compatible version and it's not packaged in
debian, or someone forked a py3k version, which is now incompatible
with the py2 version, and so many other different variations.
put the work in, and when we are close to a stall situation and/or
close to the freeze we can evaluate what to do, with drastic decisions
too.
> > (and removing a py2
> > package from a leaf pkg takes 5 minutes, usually, so if everyone in
> > this thread had done that instead of writing an email, we'd be down 5
> > bugs already :D )
>
> I probably have done hundreds of them already. And I do not agree that
lol including
https://tracker.debian.org/news/1065995/accepted-cherrypy3-891-3-source-all-into-unstable/
which broke calibre
you're approach is sometimes reckless and you should re-evaluate it.
Sadly many others did the same, and reverse dependencies broke because
maintainers dropped packages without verify if they were leaf pkgs
first.
Debian is not about speed, is about quality, if you cannot see that,
there's no amount of emails that will change it.
> it takes just 5 minutes. For a trivial leaf package, probably, but when
> you're trying to fix a long chain of dependencies, it can sometimes be a
> non-trivial work. Going from the leaf package and rewinding can
> sometimes lead to mistakes.
even a long chain starts from a leaf package. you fix that and then
you move one step closer. it does not add complexity (as it's the same
set of actions, generally) just time.
> > I think it's also extremely premature (and just a bad idea in general)
> > to consider breakage of reverse dependencies but just dropping py2
> > packages. the Release Team is extremely unhappy with this approach for
> > dealing with the py2removal bugs, so let's not even consider that
> > option.
>
> Yes. Which is why we should raise severity of bugs to RC, and probably
> even remove packages if we need to. Otherwise, this process will take
> forever (ie: longer than a Debian release cycle).
you're missing the point. what is and is not RC is the release team
decision. there is no release goal for the removal of python2 so how
can it be release critical? what belongs or doesnt belong in testing
is again the release team decision. so what would it give us to remove
those packages from testing?
as of now, there are still 1800+ bugs opened tagged py2removal, do you
think it's sane to mark them as RC? please also note there are several
bugs missing too (i'm working on figuring them out, and current count
is ~400 still to report, i'll do so when i finished verifying they are
accurate).
I believe it's unthinkable to raise so many bugs to RC at this stage.
remember also there's always a chance we're gonna release python2 with
bullseye, we'll see when we're close to the release.
if we need more visibility, i can extend some of the tools i already
have (f.e. to create the tracking webpage) to tags bugs, add/update
blocks, and/or any other kind of bugs management.
Regards,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi
Reply to: