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

[Giovanni Biscuolo]

Hi Liliana

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

> Am Mittwoch, dem 13.09.2023 um 11:27 -0400 schrieb Maxim Cournoyer:

[...]

> I do wonder how the ChangeId would work in practice.

It's a «tag to track commits across cherry-picks and rebases.»

It is used by Gerrit to identify commits that belong to the same review:
https://gerrit-review.googlesource.com/Documentation/user-changeid.html

We could use it for the same purpose and instead of building a web
application for code review, "simply" count that all 'Change-Id's in a
patchset have been pushed to the Guix official repo to declare the
related bug report closed.

> Since it's not really assigned by the committer, it would have to be
> generated "on the fly" and attached to the mail in between

Not to the mail, to the commit msg! [1]

> which could result in all kinds of nasty behaviour like unstable Ids
> or duplicated ones.

No, modulo hook script bugs obviously.

> Also, if we can automate this for ChangeIds, we could also automate
> this for patch-sets – the last patch in the series just gets the
> Closes: tag added by mumi.  

The idea is that, but we don't need to add "Closes" to the commit msg
(via post-receive hook), we "just" need the hook to send an email to
NNNN-done on behalf of the committer (the committer, not the
contributor).

> Furthermore, I'm not convinced that it would ease the issue of
> forgotten bugs as you can't really apply them to the past.

No, this 'Change-Id' is not intended for past bug reports since we
**must not** rewrite past commits _because_ commit messages are
/embedded/ in commit objects.

...but for this purpose we could use git-notes, **if** wanted:
https://git-scm.com/docs/git-notes :-D

> So the practical use is limited to the case where you intentionally
> cherry- pick this or that commit from a series.

No: the practical use is that for each guix-patch bug report we can
count how many [PATCH]es are left to be committed and act accordigly,
for example notify all involved parties (contributor, committer,
'X-Debbugs-CC's) that N/M patches from the series are still to be merged
upstream... or close the bug report if zero patches are left.

> How we want to deal with that case could be a discussion in its own
> right, and maybe ChangeIds really trump the explicit tags proposed by
> Giovanni or myself here.  Whether that justifies the cognitive
> overhead of juggling them around on every submission remains to be
> shown or disproven.

There will be no additional cognitive overhead for contributors since
'Change-Id' will be automatically managed, they can simply ignore it.

> Beyond the scope of the discussion so far, it also doesn't help us with
> duplicate or superseded patches (e.g. two series on the mailing list
> propose a similar change, because one of them has already been
> forgotten).

No, IMO there is **no** solution to this problems other than "triaging"
(id:87msxyfhmv.fsf@xelera.eu
87msxyfhmv.fsf@xelera.eu/">https://yhetil.org/guix/87msxyfhmv.fsf@xelera.eu/)

> Again, the explicit close tags would allow this case to be
> handled in an interpretable fashion.  In both cases, we do however also
> introduce the potential for incorrect tagging, which then needs to be
> resolved manually (more or less a non-issue, as it's the status quo).

There is no potential of incorret tagging when using a hook-commit-msg
[1] to add 'Change-Id'.

For the other method discussed here, there is no way to avoid users
mistyping 'Closes:' pseuto-headers in their commit messages: if mistuped
they will be ignored :-(


Cheeers, Gio'


[1] 
https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature