Re: reopening bugs closed by removal after package reintroduction?
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 Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Re: reopening bugs closed by removal after package reintroduction?
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 signature.asc Description: PGP signature
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
Re: reopening bugs closed by removal after package reintroduction?
On Wed, May 13, 2020 at 05:13:45AM -, 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 signature.asc Description: PGP signature
Re: reopening bugs closed by removal after package reintroduction?
On 2020-05-12, Paul Wise 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
Re: reopening bugs closed by removal after package reintroduction?
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
Re: reopening bugs closed by removal after package reintroduction?
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
Re: reopening bugs closed by removal after package reintroduction?
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
Re: reopening bugs closed by removal after package reintroduction?
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 Description: Binary data
Re: reopening bugs closed by removal after package reintroduction?
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 Description: Binary data
Re: reopening bugs closed by removal after package reintroduction?
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: anyone have any thoughts on reopening bugs closed by removal after package reintroduction? https://lists.debian.org/msgid-search/546c2c3d77eaef6dc2b26c7ed7663f16df847bda.ca...@debian.org If they're still valid, I don't see why not. theres no way to know if they are without doing triage 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 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. Then pick what you do based on that. i suppose you could also ask the reporter to reopen if the bug is still relevant for the reintroduced version none of the options seems great for all situations though 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 i try to reproduce then reopen+reassign for bugs that I've reported, but the close message doesn't particularly encourage doing that yeah, the same happens for versioned packages python3.1 etc pabs: oh sorry, i missed that you already made the point about versioned packages in your email 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
Re: reopening bugs closed by removal after package reintroduction?
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 Description: This is a digitally signed message part.
Re: reopening bugs closed by removal after package reintroduction?
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
