From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id KLEnOyduAGUSYQEAauVa8A:P1 (envelope-from ) for ; Tue, 12 Sep 2023 15:56:56 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id KLEnOyduAGUSYQEAauVa8A (envelope-from ) for ; Tue, 12 Sep 2023 15:56:56 +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 2FAB2E58B for ; Tue, 12 Sep 2023 15:56:55 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694527015; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=SmPSHJmicmCDXHdnXZuk2bmqN+EzFSs/cY0jg3Ni+30=; b=Q2Fpr5uTzrUXKOK+WVgHGvEOnk5Z9WU6jRzFg1U8NQyiWtiwrtvCnYBm5eeLk4d7B80p0p Lrqet1wDhf92vOxD3lawV1KN2CNGuL9uAc2cjKY0H6BI52QYuzQ39w/m2tyWZJ8G9sr4Mx fB0fXgZKpfcwRMnQ/nVpJFKCXyPbsS3CsUFee9/r446uVwZngh38o5Xpp+JDtnmH48JeDn Mi1w7WuzW94JAXBzHvkjQ+rxHD116GyXHzy9ezK7Qrcy0ljDCFl7D0HHaKy5Crv73JYIMC lPQ9nh8wCyLmxto/BzUMbB3DTiVWxpKhnwYoyXgyjiNfzqHeCMb7/LMrLVBSvw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694527015; a=rsa-sha256; cv=none; b=iKI82+FssNnR8MToz3IBCtEKiV/1QgHcUztiS0Xfok/KjVKCUZL44Lms55dJhxrZo12Xy8 kEmZtOoL8Yp2iytrSUKLleMc6cIdzi0MaWJ272Ae0tvRdDvg3DzJU0XaCxOzhVGiKvGyji ks8MNOowbwsePXYSbz25dJXfkBx+wcrGIZgqAz8STN2+cRkVXzXPkegYGthJMcvBEmTaS8 0biGSRq9ENdWhHDueqm1AKr93Upk5+iP+xCVHkISx+TeyVhUpcnbl74q/SfWkQAGt5FhY7 cSuMoCCJ6s+MfVyjp56asszvuUVLY8PfV+LTs8k1isDmZqI1QzmUFf09YeCuzQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; 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" Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qg3sG-0002Ov-8R; Tue, 12 Sep 2023 09:56:17 -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 1qg3s5-0002MP-UB for guix-devel@gnu.org; Tue, 12 Sep 2023 09:56:06 -0400 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qg3s2-0007f2-Gq for guix-devel@gnu.org; Tue, 12 Sep 2023 09:56:05 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 7E1CC30098D; Tue, 12 Sep 2023 13:55:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmOXCtw3kVgQ; Tue, 12 Sep 2023 13:55:56 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.217]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id D015E300981; Tue, 12 Sep 2023 13:55:56 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 66F0F29B4EC0; Tue, 12 Sep 2023 15:55:56 +0200 (CEST) Received: (nullmailer pid 24850 invoked by uid 1000); Tue, 12 Sep 2023 13:55:55 -0000 From: Giovanni Biscuolo To: Maxim Cournoyer , Liliana Marie Prikler Cc: guix-devel@gnu.org, Vagrant Cascadian Subject: Re: [workflow] Automatically close bug report when a patch is committed In-Reply-To: <87zg1sv3vt.fsf@gmail.com> Organization: Xelera.eu 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> Date: Tue, 12 Sep 2023 15:55:47 +0200 Message-ID: <87o7i7bin0.fsf@xelera.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=46.4.214.66; envelope-from=g@xelera.eu; helo=ns13.heimat.it X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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-Spam-Score: -6.88 X-Spam-Score: -6.88 X-Migadu-Queue-Id: 2FAB2E58B X-Migadu-Scanner: mx0.migadu.com X-TUID: Hzh8l2BpQKlF --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Maxim and Liliana, Maxim Cournoyer 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] [...] >> 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, But we actually have to close/fix/resolve/mark-as-done a bug (report), no? :-D >> which "Update Emacs to 29.2" isn't. Thus, something with a more >> neutral meaning like "Resolves" might apply better here. IMO this is just an implementation "detail", although an important one. Keywords are _just_ labels, the semantics is defined elsewhere (even when it's "implicit") and the semantics establish the behaviour we intend to implement via our algorithm we use to (re)program the git hook in order to automatically close a bug report when the committer pushes all needed patches in a bug of class "PATCH" or find it's appropriate to mark it as done when committing another class of bug (sorry for being so convoluted :-O ) 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. This means that a committer can write for example "RESOLVES:" and the meaning is the same as "do:" or "Fixes:". IMO the "superficial" semantic of the keyword apply/applies is ambiguos: does this mean: 1. the commit is part of a series of patches tracked in #bug-num thus the rest of the series is still to be worked upon (please don't close the bug report) or 2. the commit is the last one of all the patches tracked in #bug-num thus no other patch is left to be committed (please close the bug report) WDYT? > 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? 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]: =2D-8<---------------cut here---------------start------------->8--- 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 ... and start incorrectly marking incorrect bug numbers on bugs.debian.org that were meant for debbugs.gnu.org. =2D-8<---------------cut here---------------end--------------->8--- Here we have a use case in which a Guix committer is also committer of other projects using a similar git hook, with (a subset of) the _very same_ keywords we choose for our hook. That's why I proposed [2] a namespaced URI, possibly not including the URL: =2D-8<---------------cut here---------------start------------->8--- Fixes: [optional bug description] =2D-8<---------------cut here---------------end--------------->8--- (here, URI is :#) ...but then you, Maxim, suggested [3] this form: =2D-8<---------------cut here---------------start------------->8--- Fixes: bug#65738 (java-ts-mode tests) =2D-8<---------------cut here---------------end--------------->8--- (here, URI is bug#8--- : bug#@ () =2D-8<---------------cut here---------------end--------------->8--- I'm an Emacs user also and when I enable bug-reference-mode in this message buffer I still see the "bug#" part of the string: bug#65738@guix is shown as an URL (pointing nowhere since I still did not configure my Emacs properly) Maxim: do you think my proposal could work also for Emacs bug-reference-mode "machinery"? And everyone: do you think that the above proposal for an "Emacs compatible" namestaced URI could be fine for all considered usercases? >>> 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: =2D-8<---------------cut here---------------start------------->8--- From: GNU Guix git hook Reply-To: <> To: control@debbugs.gnu.org =2D-8<---------------cut here---------------end--------------->8--- and this body: =2D-8<---------------cut here---------------start------------->8--- package guix close [] quit =2D-8<---------------cut here---------------end--------------->8--- 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: =2D-8<---------------cut here---------------start------------->8--- 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. =2D-8<---------------cut here---------------end--------------->8--- 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? > 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 Yes I agree, they are two complementary approaches: I think there are usecases (many? few?) in which committer pushing to the repo are actually solving an issue in some but report, even if this is not tracked as a patch bug report. [...] > 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 ...]' 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. > 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. > 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 > 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. WDYT? Thanks, Gio' [1] id:87y1hikln6.fsf@wireframe https://yhetil.org/guix/87y1hikln6.fsf@wire= frame [2] id:87pm2pces0.fsf@xelera.eu https://yhetil.org/guix/87pm2pces0.fsf@xele= ra.eu [3] id:875y4gzu85.fsf@gmail.com https://yhetil.org/guix/875y4gzu85.fsf@gmai= l.com [4] https://www.gnu.org/software/emacs/manual/html_node/emacs/Bug-Reference= .html please also consider that bug-reference-bug-regexp can be customized ;-) [5] https://debbugs.gnu.org/server-control.html =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmUAbeMMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkSHOgQAL/vU07oB+3c0JeGnmsypy7e2Yx6c70McEawqycG ILYZv8T4LBinmsWtWY02Y5mb7BsDHAQcR4gm05VnApLHYxgiywEMuERo44lMg0A1 9hhjs3OnceUDmAd08PM8R2sCoszbgSpmDzd1FSEKOU5AZjMOKEzFebCQldmNmI0r iEg1Qu/aPA9dyXM6fw07fzWgMwgQ8tfshzV4+09DH/zNzGLC+LPQCN/GrmQGkLIh nirZ7Ibsvc2WT2fDWstTtArP3JSEs5pWyik3bO9YdsPgRLGpS2etCkOEwg+4U6TS J8U7V9wCMFLDt2iDa+7KlpxW8zqDftICSlvPNjpECAt6WPFKDJOXVaGuE+2IBlxR 1cnWZ1xjD0hTGLz7CqndjjRJYBphD4rDSdPMfOBuHkNAS3Ys/WTBQ0SUAuDWa6Li MwKC07rZxXwijo5XgtSH+Mwo19vhMAZEm4J0TJXac837txcnph+y++/crjWUtRHo je/26mQxoxDukFuokVIeLisrtFDOASRFZSVJqFFXlDaJX09cZZ7p/ELtLKJ4qq7I Q8pe7GEv4JSj3irk1ioNWmMi/7/CGYmhYo7jtBelQaMJ8wj4N6C9lk46+9oK8o1R oHPbspP27aMALtj03WgRhyMhy6/zo1BweNx6kvb1oy7DEjdFXq9tQXVqU0p+QTX1 VhKn =4Dac -----END PGP SIGNATURE----- --=-=-=--