guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Liliana Marie Prikler
Subject: Re: [workflow] Automatically close bug report when a patch is committed
Date: Tue, 12 Sep 2023 19:03:20 +0200
User-agent: Evolution 3.46.4

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

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.

> 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.
 
> 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"
I'm not sure how common this case is, but if it's needed we could add
"Part-of: [same stuff as for fixes]" which once parsed by Debbugs/Mumi
would send that notification.


Cheers



reply via email to

[Prev in Thread] Current Thread [Next in Thread]