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

[Giovanni Biscuolo]

Hi Christopher,

[note: I'm deleting the "In-Reply-To:" header and changing subject to
try to start a new thread]

Christopher Baines <mail@cbaines.net> writes:

> Giovanni Biscuolo <g@xelera.eu> 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
Description: PGP signature