Re: reopening bugs closed by removal after package reintroduction?

[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 to: