Hi Liliana, Liliana Marie Prikler <liliana.prik...@gmail.com> writes:
> Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer: >> Hi, >> >> Liliana Marie Prikler <liliana.prik...@gmail.com> writes: >> >> [...] >> >> > Maybe make that bug-guix so that it matches with the mailing list >> > name, >> > though we also need a wording for when a patch is not a bug, e.g. a >> > simple package upgrade. >> > >> > WDYT about the following >> > Applies: [patch] <namespace:#bug-number> >> > Closes: [patch] <namespace:#bug-number> >> > Resolves: [patch] <namespace:#bug-number> >> > Done: [patch] <namespace:#bug-number> >> >> I don't follow; why do we need 'Applies' ? Why do we need a >> 'namespace'. Are these things the user would need to manually know >> and enter themselves in their commit messages? > I'm just asking which wording you prefer. For the tracker, they'd mean > the same as "Fixes", but fixes imho sounds like a bug, which "Update > Emacs to 29.2" isn't. Thus, something with a more neutral meaning like > "Resolves" might apply better here. If we choose this simple scheme where the top commit of a series can be annotated with Debbugs control commands, I'd opt for: --8<---------------cut here---------------start------------->8--- Applies: #bug-number --8<---------------cut here---------------end--------------->8--- I'm not sure what [patch] or namespace add (is it for a fancy URL?), so I'd drop them. >> If so, that's adding rather than reducing friction, and I'm not sure >> it'd gain much traction. The way I see it, it needs to happen >> automatically. > I mean, the way I imagine is that you type this as part of your message > and then debbugs would do the work of closing the bug. In short, "git > push" saves you the work of writing a mail because there's a hook for > it. Perhaps both approach 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 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 ...]' 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" What mumi does internally would be something like: a) Check in its database to establish the Change-Id <-> Issue # relation, if any. b) For each issue, if issue #'s known Change-Ids are all covered by the change-ids in the arguments, close it This is a bit more complex (UDP datagram, mumi database) but it does useful work for us committers (instead of simply changing the way we currently do the work). When not provided any change-id argument, 'mumi close-issues' could run the process on its complete list of issues. Since it'd be transparent and requires nothing from a committer, it'd provide value without having to document yet more processes. -- Thanks, Maxim