all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: "Liliana Marie Prikler" <liliana.prikler@gmail.com>,
	"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 23:00:42 -0400	[thread overview]
Message-ID: <877cotv4px.fsf@gmail.com> (raw)
In-Reply-To: <86zg1pwwmw.fsf@gmail.com> (Simon Tournier's message of "Thu, 14 Sep 2023 00:12:23 +0200")

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Wed, 13 Sep 2023 at 21:14, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
>
>> 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.
>
> I think it would work using some pre-commit hook.  When one commits
> their change, this commit is run and it can pre-fill the commit
> message.  Well, that’s how I have understood the thread.

Yes; exactly like how it's done in Gerrit, if you've ever used that
(we'd reuse their hook).  It'd be enabled out-of-the-box so it'd be
transparent to users.

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

I like the 'Closes: ' trailer idea; it's simple.  However, it'd need to
be something added locally, either the user typing it out (unlikely for
most contributors) or via some mumi wizardry (it's unlikely that all
users will use mumi), which means its usage (and value) would depend on
how motivated individuals are to learn these new tricks.

On the other hands, having Change-Ids added by a pre-commit hook
automatically would means the user doesn't need to do anything special
other than using git, and we could still infer useful information at any
time (in a server hook, or as a batch process).

For this reason, I think we could have both (why not?  Change-Ids by
themselves provide some value already -- traceability between our git
history and guix-patches).

-- 
Thanks,
Maxim


  reply	other threads:[~2023-09-14  3:01 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
2023-09-13 22:12                         ` Simon Tournier
2023-09-14  3:00                           ` Maxim Cournoyer [this message]
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

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

  git send-email \
    --in-reply-to=877cotv4px.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=g@xelera.eu \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=ludo@gnu.org \
    --cc=vagrant@debian.org \
    --cc=zimon.toutoune@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.