Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 9880 bytes --]

Hello Vagrant,

sorry for the delay with this reply (maybe meanwhile someone else have
already done all or some of my considerations)

Vagrant Cascadian <vagrant@debian.org> 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:<package>

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 someway to add "extended" links
with other bug reports?  Something like:

--8<---------------cut here---------------start------------->8---

Usertags: parent_<bugnum>

--8<---------------cut here---------------end--------------->8---

Anyway using this approach makes bug managing (much?) _harder_ because:

1. we have no automatic mechanism to mark the referenced bug
relationship; e.g. if I add to #100 the bug #101 as parent, bug #101
should have #100 as child, and so on for each relationship.

2. managing pseudo-headers cannot be done via server-control commands
[2]

> but bugs can be marked as blocking other bugs... this would make some
> sense in splitting patch series into multiple bugs, marking blocking
> bugs for patches that are dependent on others. But I suspect that
> would be painful in practice in many cases.

In my experience splitting bugs is often useful when managing bug
reports, because you know... ouch; but splitting is also une of the most
painful activity to do, with _every_ bug report tracking system I know
of.

AFAIU splitting bug reports in Debbugs can be done with the clone
command [2]:

--8<---------------cut here---------------start------------->8---

clone bugnumber NewID [ new IDs ... ]

The clone control command allows you to duplicate a bug report. It is useful in the case where a single report actually indicates that multiple distinct bugs have occurred. "New IDs" are negative numbers, separated by spaces, which may be used in subsequent control commands to refer to the newly duplicated bugs. A new report is generated for each new ID.

Example usage:

        clone 12345 -1 -2
        reassign -1 foo
        retitle -1 foo: foo sucks
        reassign -2 bar
        retitle -2 bar: bar sucks when used with foo
        severity -2 wishlist
        clone 123456 -3
        reassign -3 foo
        retitle -3 foo: foo sucks
        merge -1 -3

--8<---------------cut here---------------end--------------->8---

Doable but not much straightforward, it wold be much better if bugs were
splitted my submitter (but in my experience sometimes submitters are
lazy :-) )

[...]

>>> 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.
>
> With old patches, honestly, it might bring attention back to an issue to
> close it. When I get a bug closed notification, I definitely check to
> make sure the issue is actually fixed, or did not introduce other
> surprises...

I someway agree with you, but this "let's close old bugs, just reopen it
if needed" should probably be a scheduled _amd_ coordinated effort
between Guix contributors, a sort of meta-hackaton for Guix bugs :-D

> I am not saying I think we should just blindly close old bugs with
> patches, but processes that err slightly on the side of closing old
> ones, perhaps with a message "please verify if the issue is actually
> closed, and reopen in case we have made a mistake." might be
> reasonable.

I agree, it's reasonable IMO.

IMO we should better define what does it mean "old patch" and provide an
easy way to find them; maybe a plain (is:open and tag:patch)

 https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch

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.

Anyway, whatever we decide to do with old bugs, IMO we should improve
Guix bug reporting management by having more people (I'm going to
volunteer, as soon as I get all the right tools and knowledge)
performing triaging activity and people working on bug reports making
better use of the tools and guidelines described in [3]

...maybe we should add some paragraph on this in the Guix manual, also.

WDYT?

[...]


Thanks! Gio'



[1] I was thinking of what can be done in Request-tracker, which I know
better; it allows to track this kind of links: Depends on, Depended on
by, Parents, Children, Refers to, Referred to by

[2] https://debbugs.gnu.org/server-control.html

[3] https://debbugs.gnu.org/Developer.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]