From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 yCw8C0bTAWW0DAEAauVa8A:P1 (envelope-from ) for ; Wed, 13 Sep 2023 17:20:38 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id yCw8C0bTAWW0DAEAauVa8A (envelope-from ) for ; Wed, 13 Sep 2023 17:20:38 +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 BAE0F453A5 for ; Wed, 13 Sep 2023 17:20:37 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=g+lFhfF9; 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=1694618438; 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=/jkBIbAVubSz5dm+eCL3WVkRwXNjiD+q/UxRw8+9+PE=; b=gnZGMXuDcxVYgukwbi61z1ZmZIb6QSL7apas9Sp1htq5V+ysGgylgROcVzwicrFLbP1l2+ ilXvzqEn6BBPcdi3ChCjm5ESphD/Xud4sawjfX5qfzxx6siv60v+ZzQ9e4lFET8efjP5rL xa7ZJtYyDSdd16drtyHTJS4WVPxinO/zm7AYyOqPnp/rtgpjw+9gNBMqUYPfZIG/+IZJXK NknVXfFHmHOUXGn+rr5h7Nn3HxMLeh1MaZPmw6n2s/mPW7kZE+dhEWGoOydljoA2V8JwJV 1r2OCT2B48AnrfHQAkr8vc618DGtX77hjb5LXbQIGHanFyxrf5apFyuSckyv7g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=g+lFhfF9; 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=1694618438; a=rsa-sha256; cv=none; b=NETJHoFiaUQ0RAKoj3t9ifLg4qVTAVDULw2QtjqsWgo2cf1VMDISWquDsJ4s7bN5n/nkCq xxPwiza4/4tixzSuqmkV6ry+nVBMXIiAD3OJU6TtKXhfB0g3rwW1XuCXm1/U8cuuy6gaBH gffC0q0o2YzaJyCSCm6PsHiMKJuMtH+wQR+ZBBDONGW8OCuU4tDnSeJv3agKxJS9wDgtig Gg/asaOEqcDwZ2oVrMklqLyA6ZcJfgRkoXAMLaRse9zNtaqzDl4Jd/BMOviTbcTV9ZN4ja rHB82lM7XjORidgv/Snqstxgozu/xy7aJ1of9l6iP/AIH+CGwYItDbBO/n8ttw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgReu-0004KI-Cq; Wed, 13 Sep 2023 11:20:04 -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 1qgRet-0004JK-21 for guix-devel@gnu.org; Wed, 13 Sep 2023 11:20:03 -0400 Received: from mail-vk1-xa2d.google.com ([2607:f8b0:4864:20::a2d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qgRep-0008M6-Eg for guix-devel@gnu.org; Wed, 13 Sep 2023 11:20:02 -0400 Received: by mail-vk1-xa2d.google.com with SMTP id 71dfb90a1353d-495c9eb8911so1896894e0c.2 for ; Wed, 13 Sep 2023 08:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694618398; x=1695223198; 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=/jkBIbAVubSz5dm+eCL3WVkRwXNjiD+q/UxRw8+9+PE=; b=g+lFhfF9GNmz4m2w0HPXC6UcjvBKbdCAJ3qBdopTXeLkCWWVJ4fIzB9IdgSL9xwGKh rDmZ3n8CmWT/F5wMIr/HPOVW9AdTQB9zgxh43gYHJob+uyoUqb7YUipmom9AGXAxYWrE 3ku26UwE7P1L/yT45CZ2n4daNROPj1evUDtrimnvXtGfqLjuyhM7WOFS4xT6ZIWDL3gX gXvyfSeXmWrzkgOgaL4v9XesnWhyvIyO16xoGpz+5yeODG2DkR9HpTINNwVKfir1nhj+ /VAhJhsPmmcN1ByZPTQF2BTSn5mhUU1lHZyzzIONo+/iflSSlpO6m9EyUlQRlXxP6HYz O5vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694618398; x=1695223198; 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=/jkBIbAVubSz5dm+eCL3WVkRwXNjiD+q/UxRw8+9+PE=; b=fk9hw/IeT95cA0goKNLe03MAKjFp+XrKwGtsTZ6S6Jio5F6Vu1DAcDIwKFMgE5rK/i CgKLUqrxCshp+RIn0Z6ObUyxW+gskj0B4pd0gatqNYuDZp5yuzXSaRiOKxTQ97F7ypzD 6fs8rwYKEd0lXxp7o1i2XCwbFRLWI9ib6/IyBcJtjm1xQIABSzuDZ1jINNyvcNpaRUFv 5AcY59hwRcDrS1Ld710stO7YAu8Z0KTBaqJQVw7g1RdVGmKhC5jFIYDAjpwWdxCMyQqm I8OH+NaCYSGemAERSRxgYoKcv8TqOBn6x1SutA07NJa9mZZgaN6LT2l6iWtSFnonDgQn 4quA== X-Gm-Message-State: AOJu0Yxol1ywMHsMTtW0SJ3byEehWIYPNEfTSYkyic/dNVDbnKroSltv N4wPPMmS1vCt9Qs0hles1t5W5wSHih4= X-Google-Smtp-Source: AGHT+IEcu8yddkeXp/LhJ/dmy3AiMvNjIIT6XUzOAIHTsthpCwk0nPnVTVFTfkPLl/7PXbGbPYhBXw== X-Received: by 2002:a1f:4a07:0:b0:495:b905:d811 with SMTP id x7-20020a1f4a07000000b00495b905d811mr2670366vka.9.1694618397611; Wed, 13 Sep 2023 08:19:57 -0700 (PDT) Received: from hurd (dsl-149-165.b2b2c.ca. [66.158.149.165]) by smtp.gmail.com with ESMTPSA id 22-20020ac85956000000b004116b082feesm290014qtz.75.2023.09.13.08.19.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Sep 2023 08:19:56 -0700 (PDT) From: Maxim Cournoyer To: Giovanni Biscuolo Cc: Liliana Marie Prikler , guix-devel@gnu.org, Vagrant Cascadian 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> <87zg1sv3vt.fsf@gmail.com> <87o7i7bin0.fsf@xelera.eu> Date: Wed, 13 Sep 2023 11:19:55 -0400 In-Reply-To: <87o7i7bin0.fsf@xelera.eu> (Giovanni Biscuolo's message of "Tue, 12 Sep 2023 15:55:47 +0200") Message-ID: <87ledaw15w.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::a2d; envelope-from=maxim.cournoyer@gmail.com; helo=mail-vk1-xa2d.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: -1.11 X-Spam-Score: -1.11 X-Migadu-Queue-Id: BAE0F453A5 X-TUID: xDUNYya0kxJw Hi Giovanni, Giovanni Biscuolo writes: [...] >>>> Liliana Marie Prikler writes: > >>>> > WDYT about the following >>>> > =C2=A0 Applies: [patch] >>>> > =C2=A0 Closes: [patch] >>>> > =C2=A0 Resolves: [patch] >>>> > =C2=A0 Done: [patch] [...] > Anyway, I agree with Liliana that having more keyworks will help humans > better capture (and remember) the implied semantics (that we should > definitely document, anyway); for this reason my proposal is to accept > all this _lowercased_ keywords (all followed by a ":" with NO spaces in > between): fix, fixes, close, closes, resolve, resolves, do, done. OK, I now get the point; we're not discussing synonyms but various actions both 'Closes and 'Fixes' would be implement via the NNNNN-done@debbugs.gnu.org special email sent to the control server, but they convey a different idea to us humans. I agree. [...] >> 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--- > > Uh I think I get it: you mean we could use a keyword in the commit > message to allow the committer to effectively link a commit to a > #bug-number, right? Yes! I think my thought train went that way while Liliana and yours were more focused on a post push action to close *fixed* issues, right? What I described here was a general process by which we could close *patches* series that were forgotten in an 'open' state. > This is something we sould consider, but it's another topic: how to > effectively link commits to #bug-num (I guess we already talked about > this in some other thread) > >> I'm not sure what [patch] or namespace add (is it for a fancy URL?), so >> I'd drop them. > > I'll try to recap, sorry for the repetitions! > > Namespace has been assumed as part of the proposed URI to try address > Vagrant's concerns [1]: > > > Sooooo... I maintain the guix package in Debian, and want to make sure > that whatever bug-closing indicator guix upstream uses, does not end up > triggering when I push new upstream versions to salsa.debian.org ... a= nd > start incorrectly marking incorrect bug numbers on bugs.debian.org that > were meant for debbugs.gnu.org. I don't understand how this risk could be triggered; we're strictly talking about commits made in the Guix repository, not in one of Debian's? Why/how would a Guix commit message trigger a Debian Debbugs server action? Maybe if Vagrant put something like: Fixes: that could cause problems? But then the URL is different, so we could filter out these, so I don't see the problem, if we use URLs. And if we accept just 'Fixes: #NNNNN', it should be documented that these are strictly intended to refer to Guix issues, not that of other projects. I don't think we'll be able to make this error proof, so we should instead aim to make it convenient for the main use cases, which is to refer to Guix issues. Does that make sense? > Fixes: [optional bug description] > > (here, URI is :#) > > ...but then you, Maxim, suggested [3] this form: > > Fixes: bug#65738 (java-ts-mode tests) Note that we can stick with the URL and achieve the same result with some extra config (see: bug#65883). >>>> 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. > > I guess all of us are looking for this very same thing: a server side > web hook that automatically closes bugs (via email) when committers > pushing "instructs" it to do so. > > The automatic email message will be sent to our "bug control and > manipulation server" [5], with this header: > > > From: GNU Guix git hook > Reply-To: <> > To: control@debbugs.gnu.org > > > and this body: > > > package guix > close [] > quit > > > The "Reply-To:" (I still have to test it) will receive a notification > from the control server with the results of the commands, including > errors if any. > > Then, the documentation for the close command [5] states: Note that 'close' is deprecated in favor of 'done', which does send a reply. > A notification is sent to the user who reported the bug, but (in > contrast to mailing bugnumber-done) the text of the mail which caused > the bug to be closed is not included in that notification. > > If you supply a fixed-version, the bug tracking system will note that > the bug was fixed in that version of the package. > > Last but not least, the very fact that "GNU Guix git hook" have closed > the bug report is tracked and showed in the bug report history, as any > other action made via email using the Debbugs control server. > > WDYT? Yes, these last bits are what an implementation would have to do, whether it's a simple hook working from Git trailers or the more complex idea I had working from mumi and mapping commit sets (via Change-Ids) to Debbugs guix-patches issues. > [...] > >> The process (*for closing lingering *guix-patches* issues) 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 ...]' > > I think that extending the already existing post-receive hook is better > since it does not depend on the availability of a remote service > receiving a **UDP** datagram. > > For sure, we need an enhanced version of mumi CLI (capable of indexing > Change-Id) on the server running the post-receive hook to achieve this. >> 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" > > Interesting! This could also be done by a server post-receive hook, in > contrast to a remote service listening for UDP datagrams. The reason in my scheme why the more capable mumi CLI would be needed is because closed series would be inferred from commits Change-IDs rather than explicitly declared. >> 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 > > I think that b) is better suited for a git post-receive hook and not for > mumi triggered by a third service; as said above for sure such a script > needs mumi (CLI) to query the mumi (server) database. To clarify, the above should be a sequential process; with the Change-Id scheme, you don't have a direct mapping between a series and the Debbugs issue -- it needs to be figured out by checking in the Mumi database. >> 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). > > I agree: an automatic bug closing "machinery" when patches are pushed to > master (and any other official branch?) is the best approach > >> When not provided any change-id argument, 'mumi close-issues' could run >> the process on its complete list of issues. > > Do you mean the list of issues provided by "Close/Fix/Resolve: > #bug-number"? > > If I don't miss something, again this is someting that should be > provided by a git post-receive hook and not by an enhanced version on > mumi It could process the 'Fixes: #NNNNN' and other git trailers we choose to use as well, but what I had on mind was processing the *guix-patches* outstanding Debbugs issues based on the presence of unique Change-Ids in them. It complements the other proposal as it could be useful for when a committer didn't specify the needed trailers and forgot to close the issue in *guix-patches*, for example. >> Since it'd be transparent and requires nothing from a committer, it'd >> provide value without having to document yet more processes. > > No, but we should however document the design of this new kind of > machinery, so we can always check that the implementation respects the > design and eventually redesign and refactor if needed. Yes, it should be summarily described at least in the documentation, with pointers to the source. Oof, that's getting long. To recap: We have two propositions in there: 1. A simple one that is declarative: new git trailers added to commit messages would convey actions to be done by the server-side hook. 2. A more complex one that would allow us to close *some* (not all) of the *guix-patches* issues automatically, relying on Change-Ids (and Mumi's ability to parse them) to infer which patch series saw all their commits merged already. I think both have value to be pursued, but 1. could be implemented first since it is simpler. Thanks, Maxim