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

[Maxim Cournoyer]

Hi Liliana,

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

> Hi Maxim,
>
> Am Montag, dem 11.09.2023 um 16:41 -0400 schrieb Maxim Cournoyer:
>> [...]
>> Perhaps both approach[es] 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 thing is, we're discussing the same basic workflow (which you lay
> out below), just different kinds of metadata that we'd have to attach
> to our commits.  IIUC ChangeIds need to actually be carried around by
> the committers as they e.g. rewrite patches (rebasing, squashing, what
> have you), and they're basically opaque hashes so I don't see the
> benefit to the reader.  (I think you might be arguing that the benefit
> is uniqueness, but I'm not sure if I ought to buy that.)

Correct; the Change-Ids must be preserved when rebasing ((*if* they were
already published -- otherwise it doesn't matter)), and for the human
reader they're mostly noise.  Since it can be automated though, from the
day it's added all the commits would have one and they would become a
valuable unique key to cross-reference between what's in master and what
was reviewed in guix-patches, for example.

> Meanwhile "Fixes: [whatever notation]" also needs to carried around,
> sure, but at the same time provides semantics by pointing to a (known)
> bug report.  Now again, I personally prefer cool URLs here, but that's
> a bike we can shed however we want.

That's nice, and as I wrote in my previous reply to Giovanni, I think
both schemes have their place.

>> 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 ...]'
> Yeah, I think we basically agree on the 1 and 2 here, but I don't think
> we have to really implement 3.  IMHO we could do something simpler for
> all parties by just carrying the bug number around (in whichever form),
> which we do for some of our pre-ChangeLog explanations already.

For just closing cross-referenced bugs, I agree.  For closing forgotten,
already merged issues on guix-patches we'd need the Change-Id and a tool
able to map Change-Ids -> issue number (mumi is in the best place to do
so).

It's been a hard discussion to follow, but I think we're coming to some
understanding that we are discussing two different schemes that could be
both implemented to provide different benefits, right?

-- 
Thanks,
Maxim