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

[Giovanni Biscuolo]

Hi Maxim and Liliana,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

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

>>> > 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'm just asking which wording you prefer.  For the tracker, they'd mean
>> the same as "Fixes", but fixes imho sounds like a bug,

But we actually have to close/fix/resolve/mark-as-done a bug
(report), no?  :-D

>> which "Update Emacs to 29.2" isn't.  Thus, something with a more
>> neutral meaning like "Resolves" might apply better here.

IMO this is just an implementation "detail", although an important one.

Keywords are _just_ labels, the semantics is defined elsewhere (even
when it's "implicit") and the semantics establish the behaviour we
intend to implement via our algorithm we use to (re)program the git hook
in order to automatically close a bug report when the committer pushes
all needed patches in a bug of class "PATCH" or find it's appropriate to
mark it as done when committing another class of bug (sorry for being so
convoluted :-O )

Anyway, I agree with Liliana that having more keyworks will help humans
better capture (and remember) the implied semantics (that we should
definitely document, anyway); for this reason my proposal is to accept
all this _lowercased_ keywords (all followed by a ":" with NO spaces in
between): fix, fixes, close, closes, resolve, resolves, do, done.

This means that a committer can write for example "RESOLVES:" and the
meaning is the same as "do:" or "Fixes:".

IMO the "superficial" semantic of the keyword apply/applies is ambiguos:
does this mean:

1. the commit is part of a series of patches tracked in #bug-num thus
the rest of the series is still to be worked upon (please don't close
the bug report)

or

2. the commit is the last one of all the patches tracked in #bug-num
thus no other patch is left to be committed (please close the bug
report)

WDYT?

> 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---

Uh I think I get it: you mean we could use a keyword in the commit
message to allow the committer to effectively link a commit to a
#bug-number, right?

This is something we sould consider, but it's another topic: how to
effectively link commits to #bug-num (I guess we already talked about
this in some other thread)

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

I'll try to recap, sorry for the repetitions!

Namespace has been assumed as part of the proposed URI to try address
Vagrant's concerns [1]:

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

   Sooooo... I maintain the guix package in Debian, and want to make sure
   that whatever bug-closing indicator guix upstream uses, does not end up
   triggering when I push new upstream versions to salsa.debian.org ... and
   start incorrectly marking incorrect bug numbers on bugs.debian.org that
   were meant for debbugs.gnu.org.

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

Here we have a use case in which a Guix committer is also committer of
other projects using a similar git hook, with (a subset of) the _very
same_ keywords we choose for our hook.

That's why I proposed [2] a namespaced URI, possibly not including the
URL:

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

Fixes: [optional bug description] <namespace:#bug-number>

--8<---------------cut here---------------end--------------->8---
(here, URI is <namespace>:#<bug-number>)

...but then you, Maxim, suggested [3] this form:

--8<---------------cut here---------------start------------->8---
Fixes: bug#65738 (java-ts-mode tests)
--8<---------------cut here---------------end--------------->8---
(here, URI is bug#<bug-number)

That is nice since it is shown as a URL in Emacs with the minor mode
bug-reference-mode enabled, so bugs can be consulted easily (by Emacs
users); this is documented in Emacs manual "29.7 Bug Reference" [4].

I (still?!?) ignored that Emacs feature, wow! :-D (Note to self: improve
your emacs-foo)

Given all this, I propose this generalized form:

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

<keyword>: bug#<bug-num>@<namespace> (<bug title>)

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

I'm an Emacs user also and when I enable bug-reference-mode in this
message buffer I still see the "bug#<num>" part of the string:

bug#65738@guix

is shown as an URL (pointing nowhere since I still did not configure my
Emacs properly)

Maxim: do you think my proposal could work also for Emacs
bug-reference-mode "machinery"?

And everyone: do you think that the above proposal for an "Emacs
compatible" namestaced URI could be fine for all considered usercases?

>>> 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.

I guess all of us are looking for this very same thing: a server side
web hook that automatically closes bugs (via email) when committers
pushing "instructs" it to do so.

The automatic email message will be sent to our "bug control and
manipulation server" [5], with this header:

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

From: GNU Guix git hook <noreply@gnu.org>
Reply-To: <Committer> <<committer-email>>
To: control@debbugs.gnu.org

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

and this body:

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

package guix
close <bug-number> [<commit-hash>]
quit

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

The "Reply-To:" (I still have to test it) will receive a notification
from the control server with the results of the commands, including
errors if any.

Then, the documentation for the close command [5] states:

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

A notification is sent to the user who reported the bug, but (in
contrast to mailing bugnumber-done) the text of the mail which caused
the bug to be closed is not included in that notification.

If you supply a fixed-version, the bug tracking system will note that
the bug was fixed in that version of the package.

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

Last but not least, the very fact that "GNU Guix git hook" have closed
the bug report is tracked and showed in the bug report history, as any
other action made via email using the Debbugs control server.

WDYT?

> 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

Yes I agree, they are two complementary approaches: I think there are
usecases (many? few?) in which committer pushing to the repo are
actually solving an issue in some but report, even if this is not
tracked as a patch bug report.

[...]

> 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 ...]'

I think that extending the already existing post-receive hook is better
since it does not depend on the availability of a remote service
receiving a **UDP** datagram.

For sure, we need an enhanced version of mumi CLI (capable of indexing
Change-Id) on the server running the post-receive hook to achieve this.

> 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"

Interesting!  This could also be done by a server post-receive hook, in
contrast to a remote service listening for UDP datagrams.

> 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

I think that b) is better suited for a git post-receive hook and not for
mumi triggered by a third service; as said above for sure such a script
needs mumi (CLI) to query the mumi (server) database.

> 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).

I agree: an automatic bug closing "machinery" when patches are pushed to
master (and any other official branch?) is the best approach

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

Do you mean the list of issues provided by "Close/Fix/Resolve:
#bug-number"?

If I don't miss something, again this is someting that should be
provided by a git post-receive hook and not by an enhanced version on
mumi

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

No, but we should however document the design of this new kind of
machinery, so we can always check that the implementation respects the
design and eventually redesign and refactor if needed.

WDYT?

Thanks, Gio'



[1] id:87y1hikln6.fsf@wireframe https://yhetil.org/guix/87y1hikln6.fsf@wireframe

[2] id:87pm2pces0.fsf@xelera.eu 87pm2pces0.fsf@xelera.eu">https://yhetil.org/guix/87pm2pces0.fsf@xelera.eu

[3] id:875y4gzu85.fsf@gmail.com 875y4gzu85.fsf@gmail.com">https://yhetil.org/guix/875y4gzu85.fsf@gmail.com

[4] https://www.gnu.org/software/emacs/manual/html_node/emacs/Bug-Reference.html
please also consider that bug-reference-bug-regexp can be customized ;-)

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

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature