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

[Giovanni Biscuolo <g@xelera.eu>]

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

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>>> Let's avoid manual gardening as much as possible! :-)
>>
>> I like the idea!
>
> I think that automatizing is not trivial.  Sadly.

If we "restrict" the automation to "close the bugs that are listed in
the commit message" do you think it's doable?

[...]

> The potential issue is the number of false-positive;

In the context given above, the only way to have a false positive is
that the committer give a wrong bug number, right?

> closing and the submission is not applied.

I don't understand: what do you mean by "submission"?

By design:

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

The post-receive hook runs after the entire process is completed and can be used to update other services or notify users.

--8<---------------cut here---------------end--------------->8---
(https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)

In this case the "other service update" is "close bug <number>" and is
guaranteed to be done after the commit is applied.

> Maybe patchwork already running (I think) could help, trying to
> regularly rebase the branch dedicated to the submission on the top of
> master, then if all is fine, somehow the two heads from the master
> branch and the dedicated branch should match, and it would indicate the
> patches are included and it is safe to close.  More or less. :-)

I'm lost :-D

> That’s said, I always find annoying to loose the track between the Git
> history and the discussion that happened in the tracker.  Sometimes,
> rational of some details of the implementation had been discussed in the
> tracker and it is impossible to find then back.  Therefore, I would be
> in favor to add ’Close #1234’ in the commit message, say the first one
> from the series tracked by #1234.  Doing so, it would ease automatic
> management of guix-patches.  However, it would add again some burden on
> committer shoulder.

I completely agree that (often, seldom?) we miss traceability if we do
not link a commit with a bug report (when present) and vice versa (when
a bug report is resolved by a series of commit)

> Similarly, we are already adding in the commit message something like
> ’Fixes <https://issues.guix.gnu.org/issue/1234>’.

Is this an informal convention or is this documented somewhere?

> And that could be used for closing.

Yes, we can use al list of keywords for closing (Closes, Close, Fix,
Fixes, etc.), but for the bug report I'd use only a number, the URL
really does not matter

> Again, the concern is about false-positive; closing when it should not
> be.

Modulo a programming error in the script, the only way would be to write
the wrong bug number after the "keyword" and IMO this is similar write
the wrong bug number in the "To:" field when closing a bug via email.

> Well, I think that automatizing is not trivial. :-)

Not trivial but automatable, IMO :-D

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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