Re: dropping python2 [was Re: scientific python stack transitions]
On Monday, July 8, 2019 5:45:17 PM EDT Thomas Goirand wrote:
> On 7/8/19 6:28 PM, Stewart Ferguson wrote:
> > On 2019-07-08 00:13:45, Thomas Goirand wrote:
> >> On 7/7/19 5:31 PM, Matthias Klose wrote:
> >>> you can start dropping it now, however please don't drop anything yet
> >>> with
> >>> reverse dependencies. So leaf packages first.
> >>
> >> I'm sorry, but I think I need to contest this. Doing things in order,
> >> first leaf, then go all the way back, will take too long, and this is
> >> IMO unnecessary effort.
> >
> > I maintain tuna, a leaf package. Upstream is working on the py2->py3
> > migration. I expect it to be ready this cycle. I was planning to replace
> > the py2 deps with that upstream release. I can release a stripped down
> > (headless) version in python3 and I'll do that if my package is going to
> > be removed, but I'd rather wait for upstream's py3 release.
>
> Everyone would like to have better upstream. For OpenStack, swift (the
> object storage) is still there, without a full Py2 support. I don't want
> to loose Swift, though if it is removed from Testing for a short time,
> while upstream finishes to fix things, it's not a big deal, there's
> always Buster where it can be consumed in the mean time. Do you feel
> differently for your own package?
>
> > Can we set dates for removing packages so maintainers can plan what's
> > happening?
> We already have setup dates: right after Buster is released. This was
> last Saturday. Could you explain why we should delay it more, and how
> this will be beneficial to the Python 2 removal plan?
>
> > I suspect it wouldn't be hard to build a tree from an apt-rdepends graph
> > to set up a schedule, guaranteeing all traces of python2 are removed by
> > bullseye and defining the latest possible removal dates for each package
> > in testing.
> A constantly updated graph of Python 2 dependencies would definitively
> be super helpful so we could walk through it in reverse order (as much
> as possible). This way, we could also know when we're breaking things,
> and file RC bugs when needed. Thanks a lot for this idea.
>
> Though unfortunately, I'm not convinced setting-up deadlines will work,
> given the way Debian works (ie: you cannot force any contributor to do
> something).
>
> If needed, I can provide the infrastructure (ie: a large VM hosting the
> graph, directly connected to a Debian mirror at 10 Gbits/s). Though I
> haven't played much with graphviz to produce such a graph. Does any of
> us know?
>
> What I did so far:
> debtree -R --rdeps-depth=100 python2.7 >py2.7.deps.dot
> dot -Tsvg -o py2.7.deps.svg py2.7.deps.dot
>
> The result is here:
> http://py2graph.infomaniak.ch/py2.7.deps.svg
>
> How can I get debtree to use Sid instead of Buster (as I'd prefer to
> keep this VM running Buster)? I could set this VM up and a cron job for
> how long we need it... Though it looks like I probably have over-sized it.
I think that's a useful view of the problem space, but it seems to miss some
things. I think a transition tracker would also be useful (start at the top
level, not the bottom). I'll ask the release team to set one up.
Scott K
Reply to: