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: Wed, 13 Sep 2023 21:14:52 +0200
User-agent: Evolution 3.46.4

Am Mittwoch, dem 13.09.2023 um 11:27 -0400 schrieb Maxim Cournoyer:
> 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?
I do wonder how the ChangeId would work in practice.  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, which could result in all
kinds of nasty behaviour like unstable Ids or duplicated ones.  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.  

Furthermore, I'm not convinced that it would ease the issue of
forgotten bugs as you can't really apply them to the past.  So the
practical use is limited to the case where you intentionally cherry-
pick this or that commit from a series.  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.

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

Cheers



reply via email to

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