From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id CKVaB8l7/2TfUwAA9RJhRA:P1 (envelope-from ) for ; Mon, 11 Sep 2023 22:42:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id CKVaB8l7/2TfUwAA9RJhRA (envelope-from ) for ; Mon, 11 Sep 2023 22:42:49 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5F20B4357D for ; Mon, 11 Sep 2023 22:42:48 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=A8voFmOc; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694464969; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=16AZfJpBX9lRc67IoyGX3FZU/4fJgra8qlg6asT9Smc=; b=I2/u+TEzz0SoyZ1W2csQIDWhgbR8ackx5hXLr0yTdleL0HfpKZ91o8Rqts38HDBjUCrCMw Em6JHt7GcsiPcaT6YTOBnBm99rksH9zlc4woIFJwncgo128lDfFKGgnUycJTHVl1Xd09qs QDqjQtO53UHJOTu0uhVr8mrt7oVnM8uNYPQi4ZZI9MAC8nz5qcpZngwoh9PdbjWkPiaQ6J 1NeyHCW5cawq5kJxu2wP/PZ6pGt0VDNFHhFdSQKagDTbvPV2FSSWsb56Jwcavooo4KiH/1 jgUDBIiA8QhjsS5lJQQsQtWuug7hHLtBoW8Qrff8GnTEjz3/Jq/VWR7Fin3kFw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=A8voFmOc; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694464969; a=rsa-sha256; cv=none; b=jw6wXaX0j9THToX7qZgDwxY5kKmpmbV0n/gi5JmOhBe2aU1u4aV+IfB0+yyPLlkfK1iKAh eV5HEhQyyy/+70R8kReBpRHqmLcPGnkeZr/wgewn3alZRN+kh1LSjP0eYF2xfP4xMY/Wt2 sKzS3oqI/5R76L6txBdMxkHEXIKStxwZV3LTZrG+MQO7qM0KPqdAXI9dtFIfgm8UZpJpsA AwICmTm8Z63qx5IwjWKUI/r0Umlu2eWPjMa1eWdMUwlEx7qoA+BtJP592n3a16cKWv1do6 UDsRrNH2vhPnURL04Gb072DTX0gkonljJAJfsRm3qogrWxsJVgwuJ8f/ZxB5lw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qfnjX-0004fd-Bj; Mon, 11 Sep 2023 16:42:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qfnjR-0004dK-AB for guix-devel@gnu.org; Mon, 11 Sep 2023 16:42:07 -0400 Received: from mail-oo1-xc29.google.com ([2607:f8b0:4864:20::c29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qfnjO-0007gE-Rl; Mon, 11 Sep 2023 16:42:05 -0400 Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5732481b22eso3192258eaf.3; Mon, 11 Sep 2023 13:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694464920; x=1695069720; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=16AZfJpBX9lRc67IoyGX3FZU/4fJgra8qlg6asT9Smc=; b=A8voFmOc30wqRsLJ80UWIVB/NNkxwMyyXeeoZhWzlZy7cVRmBlgz359bcDp0wKAF9z dEgOaU5jv74bthDPiqF48YfCAKfj3HR6LdK4of4uqbVsfequ1ebb0CpqEBmBT9KnRov1 gfMOUtO57WrdElxKAwkVDCmDjLwylug8kSWKA37EgnN9CaVZi0CUQ2H9sE8hd+nH05g/ gONsTZVezdrqNNBvxQaCU1NNuST4uzlZ9H6VknSolZHZQDv6L8EZ3gErvUFh/7dbMtng PuG0Rg5QYoS2TZ427m3/5otjvwjkG9FGgfBdtPFAKOoy+7I+ROEGn4/j5SxfyaVg4afW i+Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694464920; x=1695069720; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=16AZfJpBX9lRc67IoyGX3FZU/4fJgra8qlg6asT9Smc=; b=cTjKxEfmbZHtnCgDZvONvBO9cxSdBRhTwp8QGvXOzqe5P0VC7Y1+gOx+deliqnpIhU QRg3iMi+B7e9ImBkDkGeopAu5cpD3iJx3AcSUuIY50LOogNDg+5RbWjqdqCuqnecSGlY ha89t7J3Kk1I7sqo42Hq9vKSSjdd7dBxXKBRKX1VK8wJ7H0ZhB4HUwpDOboFS2VnDU0M p1Ag566tMLBPmqpVetVuczYpr2QmkOT6rerjTRW/B2UEaYjflu53aYy+JXFV8XmqcbbZ N9VOSbpezW/1Ll15M7rDSjas2cru2Nnp0cVPlQQtw4gGHsOFFaIhkcc1sMc16cLE+By2 QdoA== X-Gm-Message-State: AOJu0YwtdeW4HUT31zUoQy60wYKR+CPDZZh3PXJvOxxTTHHCj2RghGV+ px1qrUuwEGBLoslxceAFExsvCxP77ok= X-Google-Smtp-Source: AGHT+IFM61SpspCO1va6f6/10g0ooWC4IcS4emGZ3PCFv15jvQsMjN6MIda0vvHmvRXiv1MScsXugA== X-Received: by 2002:a05:6358:261c:b0:135:acfd:8786 with SMTP id l28-20020a056358261c00b00135acfd8786mr13080595rwc.3.1694464919941; Mon, 11 Sep 2023 13:41:59 -0700 (PDT) Received: from hurd (dsl-141-150.b2b2c.ca. [66.158.141.150]) by smtp.gmail.com with ESMTPSA id e18-20020a05620a12d200b007708082cdfdsm2744621qkl.123.2023.09.11.13.41.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 13:41:59 -0700 (PDT) From: Maxim Cournoyer To: Liliana Marie Prikler Cc: Giovanni Biscuolo , Vagrant Cascadian , guix-devel@gnu.org, Ludovic =?utf-8?Q?Court=C3=A8?= =?utf-8?Q?s?= Subject: Re: [workflow] Automatically close bug report when a patch is committed References: <8734zrn1sc.fsf@xelera.eu> <87edjb5le5.fsf@gmail.com> <87jzt2feq6.fsf@xelera.eu> <87y1hikln6.fsf@wireframe> <2d93b48dfd381c55ff706394ff7226133f5e014a.camel@gmail.com> <87pm2pces0.fsf@xelera.eu> <87bke8wo96.fsf@gmail.com> <929b035f6f4aca0793d9f8a6454b673b2a7069c1.camel@gmail.com> Date: Mon, 11 Sep 2023 16:41:58 -0400 In-Reply-To: <929b035f6f4aca0793d9f8a6454b673b2a7069c1.camel@gmail.com> (Liliana Marie Prikler's message of "Mon, 11 Sep 2023 20:51:05 +0200") Message-ID: <87zg1sv3vt.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::c29; envelope-from=maxim.cournoyer@gmail.com; helo=mail-oo1-xc29.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -8.07 X-Spam-Score: -8.07 X-Migadu-Queue-Id: 5F20B4357D X-TUID: Th2KdwZZoS6v Hi Liliana, Liliana Marie Prikler writes: > Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer: >> Hi, >> >> Liliana Marie Prikler 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 >> > =C2=A0 Applies: [patch] >> > =C2=A0 Closes: [patch] >> > =C2=A0 Resolves: [patch] >> > =C2=A0 Done: [patch] >> >> I don't follow; why do we need 'Applies' ?=C2=A0 Why do we need a >> 'namespace'.=C2=A0 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.=C2=A0 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=3D'Change-Id=3DXXXX'), 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. --=20 Thanks, Maxim