Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer:
>> Hi,
>>
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>>
>> [...]
>>
>> > Maybe make that bug-guix so that it matches with the mailing list
>> > name,
>> > though we also need a wording for when a patch is not a bug, e.g. a
>> > simple package upgrade.
>> >
>> > WDYT about the following
>> >   Applies: [patch] <namespace:#bug-number>
>> >   Closes: [patch] <namespace:#bug-number>
>> >   Resolves: [patch] <namespace:#bug-number>
>> >   Done: [patch] <namespace:#bug-number>
>>
>> I don't follow; why do we need 'Applies' ?  Why do we need a
>> 'namespace'.  Are these things the user would need to manually know
>> and enter themselves in their commit messages?
> I'm just asking which wording you prefer.  For the tracker, they'd mean
> the same as "Fixes", but fixes imho sounds like a bug, which "Update
> Emacs to 29.2" isn't.  Thus, something with a more neutral meaning like
> "Resolves" might apply better here.

If we choose this simple scheme where the top commit of a series can be
annotated with Debbugs control commands, I'd opt for:

--8<---------------cut here---------------start------------->8---
Applies: #bug-number
--8<---------------cut here---------------end--------------->8---

I'm not sure what [patch] or namespace add (is it for a fancy URL?), so
I'd drop them.

>> If so, that's adding rather than reducing friction, and I'm not sure
>> it'd gain much traction.  The way I see it, it needs to happen
>> automatically.
> I mean, the way I imagine is that you type this as part of your message
> and then debbugs would do the work of closing the bug.  In short, "git
> push" saves you the work of writing a mail because there's a hook for
> it.

Perhaps both approach could be combined.  I still see value in a general
scheme to automate closing applied series that linger on in Debbugs.

[0]  https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00138.html

Change-Ids would also add the benefit that any commit found in Git could
easily be traced back to their submission on the guix-patches or guix
trackers or vice-versa (git log --grep='Change-Id=XXXX'), as noted by
Giovanni.

The process could go like this:

1. commits of a series pushed to master
2. Savannah sends datagram to a remote machine to trigger the
post-commit job, with the newly pushed commits 'Change-Id' values (a
list of them).
3. The remote machine runs something like 'mumi close-issues [change-id-1
change-id-2 ...]'

In case it couldn't close an issue, it could send a notification to the
submitter: "hey, I've seen some commits of series NNNN landing to
master, but not all of the commits appears to have been pushed, please
check"

What mumi does internally would be something like:

a) Check in its database to establish the Change-Id <-> Issue # relation,
if any.

b) For each issue, if issue #'s known Change-Ids are all covered by the
change-ids in the arguments, close it

This is a bit more complex (UDP datagram, mumi database) but it does
useful work for us committers (instead of simply changing the way we
currently do the work).

When not provided any change-id argument, 'mumi close-issues' could run
the process on its complete list of issues.

Since it'd be transparent and requires nothing from a committer, it'd
provide value without having to document yet more processes.

-- 
Thanks,
Maxim