Re: Severity bump script

[Sandro Tosi]

there seems to be disagreement on how to proceed, so for the time
being i suspended the severity bump part of the py2removal tracking
script. let me know when everybody agrees on a solution, and what that
solution is, and i'll code it and re-enable.

regards,
Sandro

On Thu, Dec 5, 2019 at 6:07 AM Paul Gevers  wrote:
>
> Hi,
>
> On 03-12-2019 13:19, Matthias Klose wrote:
> > It's unfortunate that issues for some packages only get attention when the
> > severity of an issue is raised.  Following your proposal means that the 
> > issue is
> > probably ignored forever, and you don't propose a better way going forward, 
> > just
> > saying we should stop earlier.  I don't think that's the correct choice.  
> > For
> > now these seem to be single packages, so please could you name those, and 
> > we can
> > look at those with a priority?  That's at least a path that is forward 
> > looking,
> > or feel free to propose another approach better than your current proposal 
> > for
> > not getting the attention of maintainers.
>
> I guess what I'm asking for could be fulfilled by an announcement to
> d-d-a with a package list (including via which package(s) they are
> affected) attached including the standard grouping by DD. And then some
> time to react.
>
> Paul
>
> PS, my original typed reply below. After having writing it, the idea
> above emerged.
>
> My problem with the current approach is that the way that developers
> learn that they (potentially transitively) (build) depend on a Python 2
> package is by the autoremoval message. I don't think that is acceptable
> socially in the project. My proposal is to give the maintainers about
> those packages a heads up. Via a bug report may be a bit weird in cases,
> but in some cases may be the appropriate thing as the package could work
> around the (build) dependency. At least adding "affects" helps a tiny
> bit and direct e-mails to the maintainers (e.g. via the
> @packages.debian.org address will at least give them a heads
> up. Even if the RM bug is coming eventually.
>
> Again, I don't have a problem with Python 2 removal, even at the price
> of packages that don't care that their dependency is written in Python.
> I do care about proper communication. Using RC severity to trigger
> autoremoval for non-leaf packages just yet is not appropriate in the
> opinion of the release team. Even though I am well aware of the Python 2
> removal effort I can tell from personal experience (cacti) that
> receiving an autoremoval e-mail as the first sign of such a dependency
> isn't nice, that's the problem I'm having and that needs solving in my
> opinion.
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Paul Gevers]

Hi,

On 03-12-2019 13:19, Matthias Klose wrote:
> It's unfortunate that issues for some packages only get attention when the
> severity of an issue is raised.  Following your proposal means that the issue 
> is
> probably ignored forever, and you don't propose a better way going forward, 
> just
> saying we should stop earlier.  I don't think that's the correct choice.  For
> now these seem to be single packages, so please could you name those, and we 
> can
> look at those with a priority?  That's at least a path that is forward 
> looking,
> or feel free to propose another approach better than your current proposal for
> not getting the attention of maintainers.

I guess what I'm asking for could be fulfilled by an announcement to
d-d-a with a package list (including via which package(s) they are
affected) attached including the standard grouping by DD. And then some
time to react.

Paul

PS, my original typed reply below. After having writing it, the idea
above emerged.

My problem with the current approach is that the way that developers
learn that they (potentially transitively) (build) depend on a Python 2
package is by the autoremoval message. I don't think that is acceptable
socially in the project. My proposal is to give the maintainers about
those packages a heads up. Via a bug report may be a bit weird in cases,
but in some cases may be the appropriate thing as the package could work
around the (build) dependency. At least adding "affects" helps a tiny
bit and direct e-mails to the maintainers (e.g. via the
@packages.debian.org address will at least give them a heads
up. Even if the RM bug is coming eventually.

Again, I don't have a problem with Python 2 removal, even at the price
of packages that don't care that their dependency is written in Python.
I do care about proper communication. Using RC severity to trigger
autoremoval for non-leaf packages just yet is not appropriate in the
opinion of the release team. Even though I am well aware of the Python 2
removal effort I can tell from personal experience (cacti) that
receiving an autoremoval e-mail as the first sign of such a dependency
isn't nice, that's the problem I'm having and that needs solving in my
opinion.



signature.asc
Description: OpenPGP digital signature

Re: Severity bump script

[Matthias Klose]

On 02.12.19 20:28, Paul Gevers wrote:
> Hi all,
> 
> On 01-12-2019 22:45, Sandro Tosi wrote:
>> Paul, this is the thread i was talking about.
>>
>> you were copied in the original email:
>> https://lists.debian.org/debian-python/2019/10/msg00098.html
>>
>> if there is something the RT wants to discuss about this effort,
>> please do so here, not directly to me (i may be the mail address
>> sending those control commands, but the decision was taken here).
> 
> I understand the drive to push for Python 2 removal and sympathize with
> it. The issue I had yesterday with the process is that "leaf" was
> wrongly defined, it was looking at Depends, instead of also including
> Build-Depends.

that should be fixed.

> I don't want to stand in the way of Python 2 removal, but as I said
> before, pulling packages out from underneath maintainers isn't pretty so
> needs to be done with proper notifications and care. An RC bug to ones
> own package is acceptable in my opinion as it is a clear discussion
> forum, and can be (temporarily) down-graded while the discussion is
> ongoing. Being notified about some other package that I not even need
> directly but is going to pull "my" package out of testing isn't a nice
> experience and should be avoided. Yes, that slows down the process, but
> there are people, emotions and all those irrational things involved.

It's unfortunate that issues for some packages only get attention when the
severity of an issue is raised.  Following your proposal means that the issue is
probably ignored forever, and you don't propose a better way going forward, just
saying we should stop earlier.  I don't think that's the correct choice.  For
now these seem to be single packages, so please could you name those, and we can
look at those with a priority?  That's at least a path that is forward looking,
or feel free to propose another approach better than your current proposal for
not getting the attention of maintainers.

Matthias

PS: There's a RC issue for creduce now, not caused by the package itself, should
I downgrade it?

Re: Severity bump script

[Ondrej Novy]

Hi,

po 2. 12. 2019 v 20:36 odesílatel Paul Gevers  napsal:

> #942999 and #936537
>

ah right. I think this is correct. There is nothing else "in Python 2
removal process" to do on "someone else" packages. Work needs to be done in
these packages so raise severity here to unblock other bugs and continue
Python 2 removing effort.

-- 
Best regards
 Ondřej Nový

Re: Severity bump script

[Mattia Rizzolo]

On Mon, 2 Dec 2019, 10:25 pm Paul Gevers,  wrote:

> Hi,
>
> On 02-12-2019 22:15, Sandro Tosi wrote:
> > the blocks are only between py2removal packages, so if a package
> > un-related to the py2removal effort
> > depend/recomments/b-deps/autotest-triggers a py2removal *application*,
> that
> > is still considered a leaf package
>
> You'll fix that, right? Because why would the tree stop at Python? A
> leaf package is a package without Depends/Build-Depends in Debian.


Because the python2 removal is about python2.  If you depend on a python2
package then the dependant application needs to likewise be dropped or
updated, but it also is at the same time somewhat out of scope from "us".

So it's either file py2removal bugs also against packages that don't depend
on python, but just use an application that happens to use python2, or the
current status quo.
That's my take at least.

Also, I am one of those that think we should be much more forceful, and the
current situation looks just fine for me, so I might be biased.

Re: Severity bump script

[Sandro Tosi]

> You'll fix that, right? Because why would the tree stop at Python? A
> leaf package is a package without Depends/Build-Depends in Debian. (I
> appreciate it very much that you consider Recommends and
> autopkgtest-triggers as well).

so the revised logic should be:

* it's an app (package name doesnt start with 'python-' or end with -'doc')
* it has low popcorn (< 300)
* (NEW) it has "real" rdep = 0 (so the number of dependencies from
packages not from the same source pkg are 0)

is that correct or should it be something else?


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Paul Gevers]

Hi,

On 02-12-2019 22:15, Sandro Tosi wrote:
> the blocks are only between py2removal packages, so if a package
> un-related to the py2removal effort
> depend/recomments/b-deps/autotest-triggers a py2removal *application*, that
> is still considered a leaf package

You'll fix that, right? Because why would the tree stop at Python? A
leaf package is a package without Depends/Build-Depends in Debian. (I
appreciate it very much that you consider Recommends and
autopkgtest-triggers as well).

Paul



signature.asc
Description: OpenPGP digital signature

Re: Severity bump script

[Sandro Tosi]

> > huh? We are not bumping any "blocked" bugs.
> > Depends/Build-Depends/Recommends/autopkgtests usage marks bug as
> > blocked. Any example of "wrong definition" please?
>
> #942999 and #936537

the blocks are only between py2removal packages, so if a package
un-related to the py2removal effort
depend/recomments/b-deps/autotest-triggers a py2removal *application*, that
is still considered a leaf package and will get its severity
raised (cfr 
https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L544-L546
); it doesnt happen with modules are we check the "real" rdeps for
those


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Ondrej Novy]

Hi,

po 2. 12. 2019 v 20:28 odesílatel Paul Gevers  napsal:

> I understand the drive to push for Python 2 removal and sympathize with
> it. The issue I had yesterday with the process is that "leaf" was
> wrongly defined, it was looking at Depends, instead of also including
> Build-Depends.
>

huh? We are not bumping any "blocked" bugs.
Depends/Build-Depends/Recommends/autopkgtests usage marks bug as blocked.
Any example of "wrong definition" please?

-- 
Best regards
 Ondřej Nový

Re: Severity bump script

[Paul Gevers]

Hi Ondrej,

On 02-12-2019 20:33, Ondrej Novy wrote:
> Hi,
> 
> po 2. 12. 2019 v 20:28 odesílatel Paul Gevers  > napsal:
> 
> I understand the drive to push for Python 2 removal and sympathize with
> it. The issue I had yesterday with the process is that "leaf" was
> wrongly defined, it was looking at Depends, instead of also including
> Build-Depends.
> 
> 
> huh? We are not bumping any "blocked" bugs.
> Depends/Build-Depends/Recommends/autopkgtests usage marks bug as
> blocked. Any example of "wrong definition" please?

#942999 and #936537

Paul



signature.asc
Description: OpenPGP digital signature

Re: Severity bump script

[Paul Gevers]

Hi all,

On 01-12-2019 22:45, Sandro Tosi wrote:
> Paul, this is the thread i was talking about.
> 
> you were copied in the original email:
> https://lists.debian.org/debian-python/2019/10/msg00098.html
> 
> if there is something the RT wants to discuss about this effort,
> please do so here, not directly to me (i may be the mail address
> sending those control commands, but the decision was taken here).

I understand the drive to push for Python 2 removal and sympathize with
it. The issue I had yesterday with the process is that "leaf" was
wrongly defined, it was looking at Depends, instead of also including
Build-Depends.

I don't want to stand in the way of Python 2 removal, but as I said
before, pulling packages out from underneath maintainers isn't pretty so
needs to be done with proper notifications and care. An RC bug to ones
own package is acceptable in my opinion as it is a clear discussion
forum, and can be (temporarily) down-graded while the discussion is
ongoing. Being notified about some other package that I not even need
directly but is going to pull "my" package out of testing isn't a nice
experience and should be avoided. Yes, that slows down the process, but
there are people, emotions and all those irrational things involved.

Paul



signature.asc
Description: OpenPGP digital signature