Hi Liliana Liliana Marie Prikler 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 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