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

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

Re: dropping python2 [was Re: scientific python stack transitions]

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

Contents

  Re: dropping python2 [was Re: scientific python stack transitions] Stewart Ferguson <stew@ferg.aero> - 2019-07-08 18:30 +0200
    Re: dropping python2 [was Re: scientific python stack transitions] Scott Kitterman <debian@kitterman.com> - 2019-07-09 00:30 +0200
    Re: dropping python2 [was Re: scientific python stack transitions] Rick Thomas <rbthomas@pobox.com> - 2019-07-09 00:30 +0200

#11465 — Re: dropping python2 [was Re: scientific python stack transitions]

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

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.

Can we set dates for removing packages so maintainers can plan what's happening?
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.

Stewart Ferguson

[toc] | [next] | [standalone]

#11466

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

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

#11467

> On Jul 8, 2019, at 2:45 PM, Thomas Goirand <zigo@debian.org> wrote:
> 
> 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

Fascinating…
Can you give us some hints to interpret the graph?
In particular, what do the different colors on the arrows mean?

Thanks!
Rick

[toc] | [prev] | [standalone]

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

csiph-web