Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)
Hi Simon Simon Tournier writes: [...] >> is enough, but (is:open and tag:patch,moreinfo) is better: [...] >> We could also add a feature to have "saved searches" in mumi web and CLI >> interfaces to help with this task. > > Well, the Mumi CLI, “guix shell mumi” and then “mumi search”, should do > act as “saved searches”. I don't understand; I mean for example having a configuration file where we can save searches, something like: --8<---cut here---start->8--- [patches-to-be-checked] "is:open and tag:patch,moreinfo" --8<---cut here---end--->8--- and then "mumi search --saved patches-to-be-checked" ...something like notmuch, I mean. > Although it does not work for me. Please help improving mumi with bug reports or patches if you have not already done > Note that Debian provides some BTS tools, as pointed here, Yes I saw your message, useful thanks; we should package it and maybe add that functions to mumi, one by one Thanks, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)
Hi, On Mon, 11 Sep 2023 at 09:37, Giovanni Biscuolo wrote: > A more useful mumi (web or CLI) query to search for duplicates would be: > > is:open tag:patch subject: [...] > is enough, but (is:open and tag:patch,moreinfo) is better: > > https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch%2Cmoreinfo > > or even filtered if older than 5m, because "The bug will be closed if > the submitter doesn't provide more information in a reasonable (few > months) timeframe." [3] > > We could also add a feature to have "saved searches" in mumi web and CLI > interfaces to help with this task. Well, the Mumi CLI, “guix shell mumi” and then “mumi search”, should do act as “saved searches”. Although it does not work for me. Note that Debian provides some BTS tools, as pointed here, Debbugs CLI client (was Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?))) Simon Tournier Tue, 05 Sep 2023 10:58:50 +0200 id:86msy1uhbp@gmail.com https://yhetil.org/guix/86msy1uhbp@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-09 Cheers, simon
Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)
Hello Vagrant, sorry for the delay with this reply (maybe meanwhile someone else have already done all or some of my considerations) Vagrant Cascadian writes: [...] >> The point is that triaging is a (boring) activity that Someone™ should >> perform, sooner or later (as Vagrant did with the bug reports mentioned >> above). > > I was definitely in the mood for "let me get some relatively easy, if > boring things done" the other day. :) boring but very much useful: thank you! ...and thanks to all the other people that sometimes are doing this job! >> Obviously a contrubutor could (should) also be a self-triager, if she >> wants help making the review process more efficient. > > FWIW, I think I used the search: > > https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch > > Sorted by date, and searched for the phrase "update" in the subject, as > old bugs proposing to update to a newer version were and are, well, > likely candidates for culling. :) > Other tooling that could further help with the process would be > valuable. A more useful mumi (web or CLI) query to search for duplicates would be: is:open tag:patch subject: With a caveat: searched subject term could not be in the search results, since it gives bug titles, but in the /thread/ of a found bug, see bug #65809 for details WDYT? [...] > There were sometimes some things that were not merged, and I made > judgement calls on weather they still needed to be, such as a tweak to > the packaging that was maybe only needed to get an older version to > build, but the newer version was building correctly. I see and for this reason I feel triaging (for example to merge or close bugs) cannot be automated, it needs judgement [...] >> When sending a series of patches, it’s best to send a Git “cover letter” >> first, to give reviewers an overview of the patch series. >> >> --8<---cut here---end--->8--- >> >> Missing a cover letter means that triaging is harder. > > Indeed. Retitling can be used to help after the fact, at least. Right: retitling could be one of the (possibly early) triaging actions >> The issue title is from the first patch (gnu: rofi: Update to 1.7.5.) >> and IMO is somewhat confusing because the title is what appears in >> search results (Mumi, Debbugs, Emacs Debbugs). > > I retitled several bugs as well, to at least update the current status, > as a few had some patches merged or superseded, but there were > outstanding issues not yet merged. I recently learned not to confuse "subject" with "bug title"... I feel this is something contributors should always consider >> If the contrubutor sent a cover letter with subject "gnu: Update rofi >> and Add rofi-wayland (inherinting)", possibly with a little bit of >> explanation in the message body, the (now undone) early triaging would >> have been easier. > > Yes, cover letters would help significantly with triaging these more > complicated cases. > > That said, sometimes over the course of review, it becomes clear that > additional changes are needed, and it would be helpful to retitle the > bug in these cases. > > I saw at least one bug which started out as "Add XYZ" and evolved into > "Update ZXY, ... Add ABC, Add XYZ" and it would not have made sense to > make them separate patch submissions. yes: retitling is an important (re)triaging activity >> How do we solve such bug management class of problems? WDYT? >> >>> One improvement I can think of here is that QA should highlight that >>> some of the changes in each of those patch series can be found in >>> another patch series. >> >> ...and tag both bugs as related on Debbugs? > > Not sure how to mark related, Uh I see [1]: AFAIU the only available links between bugs are [2]: 1. merge bugnumber bugnumber ... --8<---cut here---start->8--- Merges two or more bug reports. When reports are merged opening, closing, marking or unmarking as forwarded and reassigning any of the bugs to a new package will have an identical effect on all of the merged reports. [...] Merger is like equality: it is reflexive, transitive and symmetric. Merging reports causes a note to appear on each report's logs; on the WWW pages this includes links to the other bugs. Merged reports are all expired simultaneously, and only when all of the reports each separately meet the criteria for expiry. --8<---cut here---end--->8--- 2. block|unblock bugnumber by|with bug [ bug ... ] --8<---cut here---start->8--- Use to note that one bug blocks another bug from being fixed. The first listed bug is the one being blocked, and it is followed by the bug or bugs that are blocking it. Use unblock to unblock a bug. --8<---cut here---end--->8--- Unfortunately "merge" is not good for two or more bugs containing "duplicated" patches. Could "Usertags" pseudo-header be used
Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)
On 2023-09-07, Giovanni Biscuolo wrote: > Christopher Baines writes: > >> Giovanni Biscuolo writes: > > [...] > >>> 20 bugs with messages similar to this one: >>> >>> >>> rofi-wayland was added in: >>> >>> 04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland. >>> >>> And updated to a newer version in: >>> >>> 19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to >>> 1.7.5+wayland2. >>> >>> Marking as done. >>> >>> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/) >>> >>> IMO we need a way automatically close this kind of bug reports... or am >>> I missing something? >> >> I think the example you give doesn't relate to what you're looking at >> below (a post-receive hook). > > Oh I see, thanks! > > This is a complex case (see below), at least not one that can be solved > by automatically closing bug reports upon commits :-O > > Sorry for the confusion I added by pointing out the wrong example, a > quick look at many bug reports made by Vagrant Cascadian last Fri and > Sat shows that many (all?) of the closed bug reports was some sort of > "duplication" of others. Vagrant please can you tell us? Yes, I think a fair amount was from "duplicate" patches. From memory, I would say many, if not most, of the bugs were due to one person submitting a patch, and someone else independently committing the same or newer version. Part of the problem with duplicates may be the difficulty of reviewing a very long poorly curated list of bugs... before issues.guix.gnu.org was a thing, it was difficult to actually find prior submissions... and it is still long enough that it is not easy. > Probably /triaging/ is one of the most critical bug report management > issue, it should be addressed properly: > > - by finding or developing triage helping tools to automate what is > possible > > - by having more people do the (boring) task of triaging bugs > > Probably we should consider adding one more contributor "level": the > triager; the triager is _not_ a reviewer (obviously not a committer), > even if she could /also/ be a reviewer and/or committer. > > The point is that triaging is a (boring) activity that Someone™ should > perform, sooner or later (as Vagrant did with the bug reports mentioned > above). I was definitely in the mood for "let me get some relatively easy, if boring things done" the other day. :) > Obviously a contrubutor could (should) also be a self-triager, if she > wants help making the review process more efficient. FWIW, I think I used the search: https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch Sorted by date, and searched for the phrase "update" in the subject, as old bugs proposing to update to a newer version were and are, well, likely candidates for culling. :) Other tooling that could further help with the process would be valuable. >> There were at least two different issues with patches for adding >> rofi-wayland [1] and [2]. >> >> 1: https://issues.guix.gnu.org/53717 > > This was to add (version "1.7.3+wayland1") and AFAIU was never committed Right, I marked this (and several others) as done because it was effectively superseded by newer versions in current guix. There were sometimes some things that were not merged, and I made judgement calls on weather they still needed to be, such as a tweak to the packaging that was maybe only needed to get an older version to build, but the newer version was building correctly. >> 2: https://issues.guix.gnu.org/59241 > > This issue have 2 patches: > > [PATCH 1/2] gnu: rofi: Update to 1.7.5. > > [PATCH 2/2] gnu: Add rofi-wayland. > > A (self-)triager should have noted two problems in that patch set > submisison: > > 1. patch contains two set of unrelated changes (?) > > Point 12. of the "check list" in 22.6 Submitting Patches > https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html > says: > > --8<---cut here---start->8--- > > Verify that your patch contains only one set of related changes. Bundling > unrelated changes together makes reviewing harder and slower. > > Examples of unrelated changes include the addition of several packages, or a > package update along with fixes to that package. > > --8<---cut here---end--->8--- That is a good reminder, there was at least one bug that seemed like a collection of "music" packages, and over time more packages were added, even after the original packages in the bug title were merged. > Is the addition of rofi-wayland related to the upgrade of rofi? > > ...probably yes, but... > > 2. multiple patches without cover letter > > https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1 > > --8<---cut here---start->8--- > > When sending a series of patches, it’s best to send a Git “cover letter” > first, to give reviewers an overview of the patch series. > > --8<---cut
[workflow] Triaging issues (was Automatically close bug report when a patch is committed)
Hi Christopher, [note: I'm deleting the "In-Reply-To:" header and changing subject to try to start a new thread] Christopher Baines writes: > Giovanni Biscuolo writes: [...] >> 20 bugs with messages similar to this one: >> >> >> rofi-wayland was added in: >> >> 04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland. >> >> And updated to a newer version in: >> >> 19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to >> 1.7.5+wayland2. >> >> Marking as done. >> >> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/) >> >> IMO we need a way automatically close this kind of bug reports... or am >> I missing something? > > I think the example you give doesn't relate to what you're looking at > below (a post-receive hook). Oh I see, thanks! This is a complex case (see below), at least not one that can be solved by automatically closing bug reports upon commits :-O Sorry for the confusion I added by pointing out the wrong example, a quick look at many bug reports made by Vagrant Cascadian last Fri and Sat shows that many (all?) of the closed bug reports was some sort of "duplication" of others. Vagrant please can you tell us? Let's call this a "triaging issue" and is a class of "management issue" that should be discussed in a separate thread (this one), to stay focused on the subject. Probably missing to "manually" close bugs after a patch set has been committed is not /the worst/ management issue currently, but IMO it's better to just "commit and forget it" :-) Probably /triaging/ is one of the most critical bug report management issue, it should be addressed properly: - by finding or developing triage helping tools to automate what is possible - by having more people do the (boring) task of triaging bugs Probably we should consider adding one more contributor "level": the triager; the triager is _not_ a reviewer (obviously not a committer), even if she could /also/ be a reviewer and/or committer. The point is that triaging is a (boring) activity that Someone™ should perform, sooner or later (as Vagrant did with the bug reports mentioned above). Obviously a contrubutor could (should) also be a self-triager, if she wants help making the review process more efficient. > There were at least two different issues with patches for adding > rofi-wayland [1] and [2]. > > 1: https://issues.guix.gnu.org/53717 This was to add (version "1.7.3+wayland1") and AFAIU was never committed > 2: https://issues.guix.gnu.org/59241 This issue have 2 patches: [PATCH 1/2] gnu: rofi: Update to 1.7.5. [PATCH 2/2] gnu: Add rofi-wayland. A (self-)triager should have noted two problems in that patch set submisison: 1. patch contains two set of unrelated changes (?) Point 12. of the "check list" in 22.6 Submitting Patches https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html says: --8<---cut here---start->8--- Verify that your patch contains only one set of related changes. Bundling unrelated changes together makes reviewing harder and slower. Examples of unrelated changes include the addition of several packages, or a package update along with fixes to that package. --8<---cut here---end--->8--- Is the addition of rofi-wayland related to the upgrade of rofi? ...probably yes, but... 2. multiple patches without cover letter https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1 --8<---cut here---start->8--- When sending a series of patches, it’s best to send a Git “cover letter” first, to give reviewers an overview of the patch series. --8<---cut here---end--->8--- Missing a cover letter means that triaging is harder. The issue title is from the first patch (gnu: rofi: Update to 1.7.5.) and IMO is somewhat confusing because the title is what appears in search results (Mumi, Debbugs, Emacs Debbugs). If the contrubutor sent a cover letter with subject "gnu: Update rofi and Add rofi-wayland (inherinting)", possibly with a little bit of explanation in the message body, the (now undone) early triaging would have been easier. How do we solve such bug management class of problems? WDYT? > One improvement I can think of here is that QA should highlight that > some of the changes in each of those patch series can be found in > another patch series. ...and tag both bugs as related on Debbugs? This would be very helful for triagers, a very helping tool. ...but we need triagers, IMO > That would then make it easier to both issues to be closed if that's > appropriate. I guess you mean that a (human) triager can find related bugs with the help of such a tool. I doubt that related issues should be closed without human intervention, false positives are very dangerous in this case. WDYT? Thanks! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc
