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

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

Re: Webpage to track py2removal bugs & packages

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

Contents

  Re: Webpage to track py2removal bugs & packages Drew Parsons <dparsons@debian.org> - 2019-09-01 19:20 +0200
    Re: Webpage to track py2removal bugs & packages Sandro Tosi <morph@debian.org> - 2019-09-01 21:00 +0200
    Re: Webpage to track py2removal bugs & packages Drew Parsons <dparsons@debian.org> - 2019-09-02 04:00 +0200
      Re: Webpage to track py2removal bugs & packages Sandro Tosi <sandro.tosi@gmail.com> - 2019-09-02 06:30 +0200
        Re: Webpage to track py2removal bugs & packages Drew Parsons <dparsons@debian.org> - 2019-09-02 10:50 +0200
          Re: Webpage to track py2removal bugs & packages Andrey Rahmatullin <wrar@debian.org> - 2019-09-02 11:00 +0200
          Re: Webpage to track py2removal bugs & packages Sandro Tosi <morph@debian.org> - 2019-09-03 06:00 +0200
            Re: Webpage to track py2removal bugs & packages Drew Parsons <dparsons@debian.org> - 2019-09-03 12:10 +0200

#11724 — Re: Webpage to track py2removal bugs & packages

Sandro Tosi wrote:
> i've prepared a small website,
> http://sandrotosi.me/debian/py2removal/index.html, to keep track of
> the bugs user-tagged `py2removal`.


It could be useful to add another column counting the Dependencies in 
the other direction.

i.e. for all the leaf packages ready for processing, which one should be 
given priority?  Which one has the most impact on Dependencies further 
down the tree?

Drew

[toc] | [next] | [standalone]

#11726

On Sun, Sep 1, 2019 at 1:15 PM Drew Parsons <dparsons@debian.org> wrote:
> It could be useful to add another column counting the Dependencies in
> the other direction.
>
> i.e. for all the leaf packages ready for processing, which one should be
> given priority?  Which one has the most impact on Dependencies further
> down the tree?

I'm afraid i dont understand the question, or maybe it's just a
different process than the one i use.

the main idea (behind the webpage) is that you cant remove a package
unless it doesnt have any reverse-dependency: so if the count it's 0,
you can go ahead and remove it.

if it has rdeps, then you need to address them _first-, and that's
where the rdeps graph comes handy, as it tells you the actual
packages.

but what i personally use is a level 4 graph (so up to 4 levels of
reverse depends): say you want to work on pkgA, but it turns out it
has some rdeps, pkg0..8; now, how many rdeps does each of these
packages have? hard to say with only a level=1 graph, as you dont see
further in the deps tree

(the risk it get crazy pretty quickly, in particular with sci
packages, as currently all debian-science tasks packages depend on the
py2 pkgs, if one of them gets pulled in it's hard to read).

Let me know if i can make the webpage more useful for you, i just dont
know how to address your request

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

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

#11731

On 2019-09-02, Sandro Tosi wrote:
> On 2019-09-02 01:15, Drew Parsons wrote:
>> Sandro Tosi wrote:
>>> i've prepared a small website,
>>> http://sandrotosi.me/debian/py2removal/index.html, to keep track of
>>> the bugs user-tagged `py2removal`.
>> 
>> 
>> It could be useful to add another column counting the Dependencies in
>> the other direction.
>> 
>> i.e. for all the leaf packages ready for processing, which one should
>> be given priority?  Which one has the most impact on Dependencies
>> further down the tree?
> 
> I'm afraid i dont understand the question, or maybe it's just a
> different process than the one i use.
> 
> the main idea (behind the webpage) is that you cant remove a package
> unless it doesnt have any reverse-dependency: so if the count it's 0,
> you can go ahead and remove it.
> 
> if it has rdeps, then you need to address them _first-, and that's
> where the rdeps graph comes handy, as it tells you the actual
> packages.


Yes, your script counts the dependencies along one direction (rdeps), 
identifying which packages are ready to be de-python2-ised next.

I'm talking about dependencies in the opposite direction, deps not 
rdeps.  Upstream vs downstream.

My question is, of the 844 packages now currently on rdeps=0 and ready 
for processing, which one should be processed first?  Which one will 
free up the largest number of upstream packages?  Which one gives the 
biggest bang for buck?

Drew

--
. please CC: me in replies

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

#11733

On Sun, Sep 1, 2019 at 9:54 PM Drew Parsons <dparsons@debian.org> wrote:
> Yes, your script counts the dependencies along one direction (rdeps),
> identifying which packages are ready to be de-python2-ised next.
>
> I'm talking about dependencies in the opposite direction, deps not
> rdeps.  Upstream vs downstream.
>
> My question is, of the 844 packages now currently on rdeps=0 and ready
> for processing, which one should be processed first?  Which one will
> free up the largest number of upstream packages?  Which one gives the
> biggest bang for buck?

gothca, i hope.

I've added the number of forward dependencies in the last update to
the webpage; it's not super-accurate (f.e. python dep is counted
twice, due to the nature of how it's produced, > 2.7 < 2.8) but it
should give a general idea of what you asked for

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

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

#11737

On 2019-09-02 12:21, Sandro Tosi wrote:
> On Sun, Sep 1, 2019 at 9:54 PM Drew Parsons <dparsons@debian.org> 
> wrote:
>> Yes, your script counts the dependencies along one direction (rdeps),
>> identifying which packages are ready to be de-python2-ised next.
>> 
>> I'm talking about dependencies in the opposite direction, deps not
>> rdeps.  Upstream vs downstream.
>> 
>> My question is, of the 844 packages now currently on rdeps=0 and ready
>> for processing, which one should be processed first?  Which one will
>> free up the largest number of upstream packages?  Which one gives the
>> biggest bang for buck?
> 
> gothca, i hope.
> 
> I've added the number of forward dependencies in the last update to
> the webpage; it's not super-accurate (f.e. python dep is counted
> twice, due to the nature of how it's produced, > 2.7 < 2.8) but it
> should give a general idea of what you asked for

Looks great, is plenty enough accurate for the task. It tells us it's 
more important to process live-task-standard than python-gnatpython-doc.

Within a given rdeps count it currently has secondary sorting made on 
Bug No. It would polish off the forward deps if they could be used for 
secondary sorting instead (highest number to lowest).  Bonus points for 
making the headers clickable so the reader can choose which secondary 
sorting is most useful (Bug No. vs Binary Pkg vs Maintainer vs # deps)

Drew

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

#11738

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

On Mon, Sep 02, 2019 at 04:43:40PM +0800, Drew Parsons wrote:
> Looks great, is plenty enough accurate for the task. It tells us it's more
> important to process live-task-standard than python-gnatpython-doc.
Not necessarily.

live-task-standard just depends on python, without any other python2 deps.
python-gnatpython-doc Recommends: python-gnatpython (which has a reverse
build dep and there is no python3-gnatpython to switch the Recommends).
I'd say both packages are not worth it. If the table displayed the number
of deps+build-deps that are themselves related to Python 2 it would be
more useful but I don't know if that's possible to implement.

-- 
WBR, wRAR

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

#11741

> Within a given rdeps count it currently has secondary sorting made on
> Bug No. It would polish off the forward deps if they could be used for
> secondary sorting instead (highest number to lowest).  Bonus points for
> making the headers clickable so the reader can choose which secondary
> sorting is most useful (Bug No. vs Binary Pkg vs Maintainer vs # deps)

with the latest update the table is initially sorted by (# rdeps, #
fdeps); i've also made the header clickable, so that you can sort the
table on that column, but it doesnt preserve sorting between clicks
(ie if you click columnA and then columnB, the sorting on cB will
loose entirely the sorting that previously was set on cA, so you cant
click on # fdeps and then #rdeps and expect to return to he initial
sorting).

since i've already all the information there, i was thinking if we
should start posting a status of the rdepends in each bug, would it be
worth the effort? i'm not sure i want to spam too frequently the BTS,
so what would be an acceptable frequency: once a week?  if we want to
pile on this, all the blocks/blockedby bts massaging could be done by
this script i guess?

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

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

#11743

On 2019-09-03 11:56, Sandro Tosi wrote:
>> Within a given rdeps count it currently has secondary sorting made on
>> Bug No. It would polish off the forward deps if they could be used for
>> secondary sorting instead (highest number to lowest).  Bonus points 
>> for
>> making the headers clickable so the reader can choose which secondary
>> sorting is most useful (Bug No. vs Binary Pkg vs Maintainer vs # deps)
> 
> with the latest update the table is initially sorted by (# rdeps, #
> fdeps); i've also made the header clickable, so that you can sort the
> table on that column, but it doesnt preserve sorting between clicks
> (ie if you click columnA and then columnB, the sorting on cB will
> loose entirely the sorting that previously was set on cA, so you cant
> click on # fdeps and then #rdeps and expect to return to he initial
> sorting).

Looks good to me. 2-state sorting is plenty good, I think.


> since i've already all the information there, i was thinking if we
> should start posting a status of the rdepends in each bug, would it be
> worth the effort? i'm not sure i want to spam too frequently the BTS,
> so what would be an acceptable frequency: once a week?  if we want to
> pile on this, all the blocks/blockedby bts massaging could be done by
> this script i guess?


I'm less certain about this.  Once a week would be too often I think.  
We're at the point now where we know the python2 decommissioning needs 
to be done. You've given us the list of packages, we just need to go 
start working on them.

Drew

[toc] | [prev] | [standalone]

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

csiph-web