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
