reopening bugs closed by removal after package reintroduction?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

reopening bugs closed by removal after package reintroduction?

Paul Wise via nm
Hi all,

One of the tasks needed when reintroducing packages after they have
been removed is that the bugs that were closed by the removal need to
be triaged and either reopened or version closing information added:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#reintroducing-packages

Should we be automatically reopening these bugs?

Should triaging these bugs be required of maintainers?

Does anyone think that triaging these bugs is a bad idea?

Does anyone want to help triage these bugs (see attached dd-list)?

Should we also be triaging the bugs filed against removed versioned
source packages like golang-1.9 or python3.6?

The attached script provided by Stuart Prescott detects reintroduced
packages and a loop around `curl | grep -F +rm` detects bugs needing
triage. I'll attempt to run this and triage bugs when I can.

--
bye,
pabs

https://wiki.debian.org/PaulWise

detect-reintroduced-packages (1K) Download Attachment
dd-list (2K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Paul Wise via nm
On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote:

> Should we be automatically reopening these bugs?

enrico suggested on IRC that we should be doing this.

> Should triaging these bugs be required of maintainers?

enrico suggested on IRC that this seems not unreasonable.

> Does anyone think that triaging these bugs is a bad idea?

There haven't been any objections thus far.

> Does anyone want to help triage these bugs (see attached dd-list)?

No volunteers yet.

> Should we also be triaging the bugs filed against removed versioned
> source packages like golang-1.9 or python3.6?

No response on this yet.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Scott Kitterman-5
On Monday, May 11, 2020 9:25:20 PM EDT Paul Wise wrote:
> > Should we also be triaging the bugs filed against removed versioned
> > source packages like golang-1.9 or python3.6?
>
> No response on this yet.

In cases like this, maintainers that want them moved can do it reasonably
easily.  I wouldn't impose the extra work on them to re-close bugs they've
consciously chosen to leave behind.

Scott K

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Paul Wise via nm
In reply to this post by Paul Wise via nm
On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote:

> One of the tasks needed when reintroducing packages after they have
> been removed is that the bugs that were closed by the removal need to
> be triaged and either reopened or version closing information added

Some discussion from #debian-devel:

<pabs> anyone have any thoughts on reopening bugs closed by removal
after package reintroduction?
https://lists.debian.org/msgid-search/546c2c3d77eaef6dc2b26c7ed7663f16df847bda.camel@...
<ScottK> If they're still valid, I don't see why not.
<pabs> theres no way to know if they are without doing triage
<pabs> so the options are either: 1) auto-reopen the bugs and force
the maintainer to do the triage 2) expect the maintainer to have read
devref and do the triage, which means it won't always happen 3) have a
dedicated team for the triage and have them possibly annoy
maintainers, make mistakes since they don't know the package etc
<ScottK> If I were a member of such a hypothetical team, I think I'd
contact the maintainer and ask them if they want the help.
<ScottK> Then pick what you do based on that.
<olly> i suppose you could also ask the reporter to reopen if the bug
is still relevant for the reintroduced version
<olly> none of the options seems great for all situations though
<olly> I've also noticed a related issue when a new upstream version
gets a new package name and then the old package is later removed and
all open bugs against it auto-closed
<olly> i try to reproduce then reopen+reassign for bugs that I've
reported, but the close message doesn't particularly encourage doing
that
<pabs> yeah, the same happens for versioned packages python3.1 etc
<olly> pabs: oh sorry, i missed that you already made the point about
versioned packages in your email
<pabs> olly: your point also applies to renamed packages rather than
versioned ones, which I hadn't thought of in my mail, so thanks :)

There were also a couple of +1 on reopening and a question about how
often packages get reintroduced (see the dd-list).

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Paul Wise via nm
In reply to this post by Paul Wise via nm
On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote:

> The attached script provided by Stuart Prescott detects reintroduced
> packages and a loop around `curl | grep -F +rm` detects bugs needing
> triage. I'll attempt to run this and triage bugs when I can.

I made a mistake when running the loop (binary vs source packages),
here is the updated dd-list. Thanks to Jochen Sprickerhof for pointing
out my mistake.

--
bye,
pabs

https://wiki.debian.org/PaulWise

dd-list (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Ulrike Uhlig
In reply to this post by Paul Wise via nm
Hi,

On 05.05.20 09:14, Paul Wise wrote:

> One of the tasks needed when reintroducing packages after they have
> been removed is that the bugs that were closed by the removal need to
> be triaged and either reopened or version closing information added:
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#reintroducing-packages
>
> Should we be automatically reopening these bugs?

On first thought it makes a lot of sense. It also seems useful to
automate this: if we rely on the maintainers to do it manually, there is
a big chance that it will be forgotten, most of the time.

Can you explain a bit better which issues this could cause to
maintainers? About how many cases per year are we talking for example?

> Should triaging these bugs be required of maintainers?

I don't understand the question. Do you mean, that when these bugs are
automatically reopened, maintainers would be required to triage them
manually? If this is what you mean, it seems like what maintainers do
anyway. Looking at your questions below, this is probably not what you mean.

> Does anyone think that triaging these bugs is a bad idea?
>
> Does anyone want to help triage these bugs (see attached dd-list)?
> Should we also be triaging the bugs filed against removed versioned
> source packages like golang-1.9 or python3.6?
>
> The attached script provided by Stuart Prescott detects reintroduced
> packages and a loop around `curl | grep -F +rm` detects bugs needing
> triage. I'll attempt to run this and triage bugs when I can.

Ulrike

Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Paul Wise via nm
In reply to this post by Paul Wise via nm
On Tue, May 12, 2020 at 6:08 AM Paul Wise wrote:

> I made a mistake when running the loop (binary vs source packages),
> here is the updated dd-list. Thanks to Jochen Sprickerhof for pointing
> out my mistake.

Sigh, attached the wrong one. Here is the correct one.

--
bye,
pabs

https://wiki.debian.org/PaulWise

dd-list (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Paul Wise via nm
In reply to this post by Ulrike Uhlig
On Tue, May 12, 2020 at 7:15 AM Ulrike Uhlig wrote:

> Can you explain a bit better which issues this could cause to
> maintainers? About how many cases per year are we talking for example?

The issue is the extra work that triaging old bugs involves, vs just
ignoring the old bugs that may or may not still apply.

The latest dd-list I posted had 22 cases of packages reintroduced
since buster that still have bugs marked as closed with a version that
ends in +rm.

> I don't understand the question. Do you mean, that when these bugs are
> automatically reopened, maintainers would be required to triage them
> manually? If this is what you mean, it seems like what maintainers do
> anyway. Looking at your questions below, this is probably not what you mean.

That is what I mean. Based on the 22 cases I posted in the dd-list,
I'm not sure folks doing package reintroductions are aware of the need
to reopen the old bugs. For the people I've approached about this so
far (before this thread), they hadn't noticed the devref section about
it.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Ulrike Uhlig
HELO,

On 12.05.20 09:26, Paul Wise wrote:

> On Tue, May 12, 2020 at 7:15 AM Ulrike Uhlig wrote:
>
>> Can you explain a bit better which issues this could cause to
>> maintainers? About how many cases per year are we talking for example?
>
> The issue is the extra work that triaging old bugs involves, vs just
> ignoring the old bugs that may or may not still apply.
>
> The latest dd-list I posted had 22 cases of packages reintroduced
> since buster that still have bugs marked as closed with a version that
> ends in +rm.

I think it makes sense to reopen these bugs automatically.

>> I don't understand the question. Do you mean, that when these bugs are
>> automatically reopened, maintainers would be required to triage them
>> manually? If this is what you mean, it seems like what maintainers do
>> anyway. Looking at your questions below, this is probably not what you mean.
>
> That is what I mean. Based on the 22 cases I posted in the dd-list,
> I'm not sure folks doing package reintroductions are aware of the need
> to reopen the old bugs. For the people I've approached about this so
> far (before this thread), they hadn't noticed the devref section about
> it.

Ulrike

Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Sune Vuorela-2
In reply to this post by Paul Wise via nm
On 2020-05-12, Paul Wise <[hidden email]> wrote:
> On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote:
>
>> Should we be automatically reopening these bugs?
>
> enrico suggested on IRC that we should be doing this.

I think in general it should be decided on a case by case basis.

if it was removed yesterday and reintroduced with almost same version
today, then probably yes.

If it was a 0.0.git-2005-01-20 removed in 2010 and version 2.0
reintroduced today, probably not.

But I guess it also depends on if it is one bug that needs work, or a
"Thanks for your contribution to Debian by maintainig this package. Now
also walk thru these 1000 old crap that probably is irellevant
today"-experience

/Sune

Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Enrico Zini
On Wed, May 13, 2020 at 05:13:45AM -0000, Sune Vuorela wrote:

> But I guess it also depends on if it is one bug that needs work, or a
> "Thanks for your contribution to Debian by maintainig this package. Now
> also walk thru these 1000 old crap that probably is irellevant
> today"-experience

I see two imperfect sides to this. On one side, as a user I report a
bug, the package drops out of Debian, the bug is ignored for a year,
then closed, the package comes back in Debian, buggy as before, and to
add insult to injury, I need to go and reopen the bug again.

On the other side, as you say, I want to package something that used to
be in Debian 5 years ago, get it into the archive, and suddenly have to
triage a number of zombie bugs.

I think there are extreme cases to both sides: a maintainer who's been
unresponsive on an important package leaving tons of users frustrated;
an old package which was popular enough to have tons of bugs, whose code
has evolved significantly so that those bugs are all mostly irrelevant
by now. Even something like, pypotetically, Gnu Interactive Tools
dropping out of Debian, getting its bugs closed, then one packages git
and gets all the previous git bugs assigned, all irrelevant.

I would however guess that, for a majority of cases, we are probably
talking about a bunch of bugs to triage, and I would rather introduce a
practice of risking having to triage some bugs more, than a way of
losing valid bugs along the way. Especially given that the time to
triage a bug should in theory be shorter than the time it took to find
it and report it, given also that the maintainer could ask users for
help.

I prefer a default of remembering which bugs were closed by the package
leaving the archive, and reopening them when the package comes back.

When that becomes insane, I would like to look at how to make it less
insane, which might also help in other situations. For example:

 - a [semi]automated way of writing to the bug saying "this is part of a
   number of bugs in an old version of the package that disappeared from
   Debian. The package has now been reintroduced after upstream
   progressed significantly, and we need help figuring out of this
   issue is still present. Could you help with triaging? This bug will
   be automatically closed in 6 months if there is no interest"
 - a way of previewing the list of bugs that would be reopened, and have
   the maintainer decide whether to keep them closed, reopen all of
   them, or pick some to reopen
 - having a way of marking bugs as "needs-triage", and encourage group
   of users to go through such bugs, try to reproduce them, and either
   close them as fixed, or report them as still found, or add clearer
   instructions for reproducing

If the problem is "one'd end up with lots of old bugs to triage", I'd
rather improve the way we get bugs triaged.

In (too) many other projects I have the experience of opening a bug as
good as I can, being ignored for years, except for a bot that
occasionally tells me "if you don't reply to this I'll close the bug and
it's your fault for not caring".


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

jrb3-beckenbach.us
[Two cents inbound from a lurker]

Greetings, Enrico Zini!

On 13 May 2020, at 05:07, you wrote:

I would however guess that, for a majority of cases, we are probably
talking about a bunch of bugs to triage, and I would rather introduce a
practice of risking having to triage some bugs more, than a way of
losing valid bugs along the way. Especially given that the time to
triage a bug should in theory be shorter than the time it took to find
it and report it, given also that the maintainer could ask users for
help.


With my “tester / customer service tech” hat on:
In theory, yes;  in practice, not as often as we’d like.
Thus I lean towards not making mass-reopen mandatory.

With my “developer / product-manager” hat on:
Knowing that these old bugs are around can be quite useful info.
Thus I lean towards making the list proactively visible.

So I like all three of your suggestions, with the second item my favorite.


Offering a naive implementation idea: 
On package reintroduction, something (bot?) files a low-priority bug
against the reintroduced package, titled eg “triage bugs from previous packaging”,
containing explanatory text (cf Enrico's) and the list of bugs which were open when the package was removed earlier.
No delayed-auto-close of this bug, though.

The interested maintainer gets the benefit of knowing what those past bugs were.
Also, of not having those bugs block current progress.
Also, of being able to do the triage on own rhythm without troubling others.

The uninterested maintainer can just ignore or close this bug.
(Successor maintainers can even go back in history and do triage more easily, if desired.)

Thanks!

Joseph


Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Enrico Zini
On Wed, May 13, 2020 at 09:27:33AM -0400, jrb3-beckenbach.us wrote:

> Offering a naive implementation idea:
> On package reintroduction, something (bot?) files a low-priority bug
> against the reintroduced package, titled eg “triage bugs from previous packaging”,
> containing explanatory text (cf Enrico's) and the list of bugs which were open when the package was removed earlier.
> No delayed-auto-close of this bug, though.
>
> The interested maintainer gets the benefit of knowing what those past bugs were.
> Also, of not having those bugs block current progress.
> Also, of being able to do the triage on own rhythm without troubling others.
>
> The uninterested maintainer can just ignore or close this bug.
> (Successor maintainers can even go back in history and do triage more easily, if desired.)
Thank you Joseph, I really like your idea!


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reopening bugs closed by removal after package reintroduction?

Giovanni Mascellani-3
In reply to this post by Paul Wise via nm
Hi,

Il 05/05/20 09:14, Paul Wise ha scritto:
> Should we also be triaging the bugs filed against removed versioned
> source packages like golang-1.9 or python3.6?

For Boost packages I manually reassign bugs that are still relevant to
the newer Boost version whenever one old version gets removed from the
archive. Fortunately Boost tend to have a relatively manageable number
of bugs, so that this does not require a terrible amount of work. Also,
it has the nice side effect to force me to retriage them periodically,
prune those that do not apply any more and remind me of the others.

(context for those who are not aware of it: the Boost library is
uploaded as a NEW versioned source package at each major release that
ends up in Debian, which the source package boost-defaults providing
versionless pure-dependency packages to the current default version)

In the specific case of Boost, I don't feel the need for an automated
procedure, because the bugs are not that many, and there is not clear
majority between bugs that need to be reassigned and those which do not.
So the amount of manual retriaging work is more or less the same. On the
other hand, I know I am doing that work anyway. Maybe at a project level
it is better to not assume that the maintainer won't be lazy, and keep
the bugs by default, giving of course the maintainer (as always) the
option to dismiss bugs that do not apply any more.

HTH, Giovanni.
--
Giovanni Mascellani <[hidden email]>
Postdoc researcher - Université Libre de Bruxelles


signature.asc (235 bytes) Download Attachment