unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: "Giovanni Biscuolo" <g@xelera.eu>,
	"Vagrant Cascadian" <vagrant@debian.org>,
	guix-devel@gnu.org, "Ludovic Courtès" <ludo@gnu.org>
Subject: Re: [workflow] Automatically close bug report when a patch is committed
Date: Wed, 13 Sep 2023 21:14:52 +0200	[thread overview]
Message-ID: <f21df8a3f1e64efb6433f3b4486786658288abe1.camel@gmail.com> (raw)
In-Reply-To: <87h6nyw0su.fsf@gmail.com>

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	other threads:[~2023-09-13 19:15 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-06  8:28 [workflow] Automatically close bug report when a patch is committed Giovanni Biscuolo
2023-09-06  9:45 ` Christopher Baines
2023-09-07  9:38   ` [workflow] Triaging issues (was Automatically close bug report when a patch is committed) Giovanni Biscuolo
2023-09-07 15:41     ` Vagrant Cascadian
2023-09-11  7:37       ` Giovanni Biscuolo
2023-09-11 15:29         ` Simon Tournier
2023-09-11 17:08           ` Giovanni Biscuolo
2023-09-06 16:14 ` [workflow] Automatically close bug report when a patch is committed Maxim Cournoyer
2023-09-07  0:23   ` Simon Tournier
2023-09-07  2:01     ` Maxim Cournoyer
2023-09-07  9:58       ` Simon Tournier
2023-09-09 23:43         ` Maxim Cournoyer
2023-09-07 13:11       ` Giovanni Biscuolo
2023-09-09 23:39         ` Maxim Cournoyer
2023-09-11  7:53           ` Giovanni Biscuolo
2023-09-11 14:01             ` Maxim Cournoyer
2023-09-11 17:10               ` Giovanni Biscuolo
2023-09-07 11:08     ` Giovanni Biscuolo
2023-09-07 11:58       ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-09-07 13:09         ` Maxim Cournoyer
2023-09-07 15:52           ` Vagrant Cascadian
2023-09-09 23:50             ` Maxim Cournoyer
2023-09-11 11:00               ` Simon Tournier
2023-09-11 13:46                 ` Maxim Cournoyer
2023-09-11 14:11                   ` Simon Tournier
2023-09-11 15:33                     ` Maxim Cournoyer
2023-09-13  2:46               ` Vagrant Cascadian
2023-09-13 15:49                 ` Maxim Cournoyer
2023-09-14 16:30                   ` Vagrant Cascadian
2023-09-14 18:02                     ` Maxim Cournoyer
2023-09-07 13:19         ` Giovanni Biscuolo
2023-09-07 10:40   ` Giovanni Biscuolo
2023-09-07 13:49     ` Giovanni Biscuolo
2023-09-27 14:36       ` Christopher Baines
2023-09-07 16:12     ` Vagrant Cascadian
2023-09-07 16:28       ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-09-09 23:59       ` Liliana Marie Prikler
2023-09-11  8:09         ` Giovanni Biscuolo
2023-09-11 13:59           ` Maxim Cournoyer
2023-09-11 17:55           ` Liliana Marie Prikler
2023-09-11 18:36             ` Maxim Cournoyer
2023-09-11 18:51               ` Liliana Marie Prikler
2023-09-11 20:41                 ` Maxim Cournoyer
2023-09-12 13:55                   ` Giovanni Biscuolo
2023-09-13 15:19                     ` Maxim Cournoyer
2023-09-14  9:42                       ` Giovanni Biscuolo
2023-09-14 16:58                         ` Liliana Marie Prikler
2023-09-12 17:03                   ` Liliana Marie Prikler
2023-09-13  9:37                     ` Giovanni Biscuolo
2023-09-13 15:27                     ` Maxim Cournoyer
2023-09-13 19:14                       ` Liliana Marie Prikler [this message]
2023-09-13 22:12                         ` Simon Tournier
2023-09-14  3:00                           ` Maxim Cournoyer
2023-09-14 10:48                             ` Giovanni Biscuolo
2023-09-15 21:46                               ` Vagrant Cascadian
2023-09-19 16:41                                 ` Giovanni Biscuolo
2023-09-14 10:27                           ` Giovanni Biscuolo
2023-09-14 12:25                             ` Simon Tournier
2023-09-15  7:16                               ` Giovanni Biscuolo
2023-09-15  9:03                                 ` Simon Tournier
2023-09-15 14:37                                   ` The already complicated (complex?) process for contributing Giovanni Biscuolo
2023-09-15 16:43                                     ` Simon Tournier
2023-09-16  7:33                                       ` Giovanni Biscuolo
2023-09-16  8:33                                         ` Simon Tournier
2023-09-14  7:20                         ` [workflow] Automatically close bug report when a patch is committed Andreas Enge
2023-09-14 10:25                         ` Giovanni Biscuolo
2023-09-14 22:51         ` Vagrant Cascadian
2023-09-15  4:23           ` Liliana Marie Prikler
2023-09-15 21:30             ` Vagrant Cascadian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f21df8a3f1e64efb6433f3b4486786658288abe1.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=g@xelera.eu \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).