From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 i+iNLM3VAmXhPgAA9RJhRA:P1 (envelope-from ) for ; Thu, 14 Sep 2023 11:43:41 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id i+iNLM3VAmXhPgAA9RJhRA (envelope-from ) for ; Thu, 14 Sep 2023 11:43:41 +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 6A8C633067 for ; Thu, 14 Sep 2023 11:43:41 +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=1694684621; 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=ABNaQcdte8+8GrKCL2z3AOYJLHZypqeiDQZtjASL6q4=; b=Ufl0tN6P5o3BobK+9KI4rARx16w/WigLKS6jZirZywKuOmgtx+XWtmBNHTlqg10Iej7hZ6 pjY32bdxcGd7evgY35ujY180qev9BkcNvJr3a0uPR5W4dj6rl1vbLTJIvjHi3gDeQqOEZ1 rUOUVs7VyBcRV8Vb9eC3PlGFfctTF0Ag+HXkSHIpM0ZP160qgGvg5Ey/X2sNgppKv51u3n 4K2wKDIE5q7kyq0x7v4a11Cd3CjH+0rytCG52bSiK1rxbY/fkoFM8sooqgD/eEblhGrjHg Da1RDFyIlH12hBNd3Kkm37ivGxJK4LC2b9R4VNPXCNyezRoBakWf2chTKFHpEg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694684621; a=rsa-sha256; cv=none; b=NFyMeumk+tQeWx0ENhkwFiRvr0hNwdxv3sDDjIBAahaZPhrTkJmijhrINcORiVLPBKdVme ClSrjoyQo/RhXgBxXQZXlazpMhbYDBlj2aVexu7nbtCH7eLbNWoBfjATqur4AqjxJa3aW5 5FEoEVeRq5Ub5270/PrqRTBp1NQ9lVneBzaIMdGrGbTORozsNceU9+wAbeYK+CMH3Ni01y NXUc5TuBZjFE1LCo+ITMTBQE2PtkujfWaFaamtz4Q9EIF/Nr/pOx+ih6+Ngj3b/gTo176X sT87BhmjppW6iFsm1qTZ+8iH+OgdK1ZJ29DcjWGouTKL1Y43/Th3VT+O4EIwsQ== 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 1qgisa-0007aA-G0; Thu, 14 Sep 2023 05:43:20 -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 1qgisX-0007Zy-0U for guix-devel@gnu.org; Thu, 14 Sep 2023 05:43:17 -0400 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgisJ-000109-W7 for guix-devel@gnu.org; Thu, 14 Sep 2023 05:43:15 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 4846C3009C0; Thu, 14 Sep 2023 09:42:56 +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 KODxZr8RYM_k; Thu, 14 Sep 2023 09:42:54 +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 F3D723009B9; Thu, 14 Sep 2023 09:42:53 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 8178629C082F; Thu, 14 Sep 2023 11:42:53 +0200 (CEST) Received: (nullmailer pid 11166 invoked by uid 1000); Thu, 14 Sep 2023 09:42:51 -0000 From: Giovanni Biscuolo To: Maxim Cournoyer , Vagrant Cascadian Cc: Liliana Marie Prikler , guix-devel@gnu.org Subject: Re: [workflow] Automatically close bug report when a patch is committed In-Reply-To: <87ledaw15w.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> <87o7i7bin0.fsf@xelera.eu> <87ledaw15w.fsf@gmail.com> Date: Thu, 14 Sep 2023 11:42:43 +0200 Message-ID: <87il8d9jl8.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: -3.38 X-Spam-Score: -3.38 X-Migadu-Queue-Id: 6A8C633067 X-Migadu-Scanner: mx0.migadu.com X-TUID: eApXF4uXlmSm --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Maxim and Vagrant, I'm sorry for some of the inconprehensions. Finally I think we got a useful design overall for the _two_ user cases and the related pieces of metadata and algorithms, now it's time for _two_ implementations proposals, that also means _code_... If nihil obstat, I'm going to open 2 bug reports (severity: wishlist) and will take ownership... but only to coordinate the work, since I miss some competence /and/ some authorization (for example to get and/or install the server side git hook) Maxim Cournoyer writes: [...] >> 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 Yes :-D [...] >>> 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! OK! :-) Let's see how this relates to the 2 use cases we are talking about: 1. Use "Fixes:" (et al) in commit msg to tell "the hook" to close the bug. This "action" implies that the commit we are pushing upstream "Applies:" to that bug report; it has no added value. 2. Use 'Change-Id'... This also implies that the commit we are pushing upstream "Applies:" to that bug report related to that [PATCH]; no added value also. So, when and only when we will implement a 'Change-Id' requirement adding an 'Applies' metadata is not useful for linking [PATCH]es to a bug report. Did I miss something? > 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? Yes, it's a (super?) /brainstorming/ :-) > What I described here was a general process by which we could close > *patches* series that were forgotten in an 'open' state. Yes: until we miss the 'Change-Id' metadata, we cannot do [1] nothing for forgotten patches series. [...] >> 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 ... = and >> start incorrectly marking incorrect bug numbers on bugs.debian.org th= at >> 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. Yes we are saying the same thing! :-) Sorry I've made confusion but Vagrant's concern was expressed _before_ someone proposed (maybe Liliana) to use namespaced URIs. Vagrant please: do you confirm that using URLs "Fixes: " is OK for your usecase? [...] >> 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 Thinking twice about this point, now I see that using the URL is **much** better than , simply because URLs can be copy/pasted in a browser for users not using the bug-reference Emacs feature or any other similar feature in their preferred IDE, if available. > with some extra config (see: bug#65883). Fantastic! [...] >> 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. Sorry I'm not finding 'done' (and the deprecation note) here: https://debbugs.gnu.org/server-control.html Maybe do you mean that we should not use the control server but send a message to -done@debbugs.gnu.org? Like: =2D-8<---------------cut here---------------start------------->8--- From: guix-commits To: -done@debbugs.gnu.org Version: This is an automated email from the git hooks/post-receive script. This bug report has been closed on behalf of <> since he added an appropriate pseudo-footer in the commit message of (see ). For details on the commit content, please see: . =2D-8<---------------cut here---------------end--------------->8--- OK: this goes in the upcoming [PATCH] and related patch revision process... :-D [...] >> 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. Yes I agree: a more capable mumi CLI is also needed in my scheme :-) The "only" difference in my scheme is that we don't need an external server listening for a UPD datagram, IMO a more capable version of our current git hooks/post-receive script is better. >>> What mumi does internally would be something like: >>> >>> a) Check in its database to establish the Change-Id <-> Issue # relatio= n, >>> 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; It was clear to me, thanks! > 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. Yes, to be precise it needs to be figured out by a tool that is indexing 'Change-Id' via Xapian. The preferred tool to be extended by the Guix project contributors is mumi, obviously ... but a similar feature could also be provided by an enhanced version of (the unofficial) guix-patches public-inbox, that uses Xapian queries for searches [2], it "just" lacks indexing messages by 'Change-Id' (is there a public-inbox CLI for searching and scripting purposes?!?) [...] > 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. Yes I think I get it :-) To be cristal clear: I think that "the other proposal" (that is use "Fixes:" and alike in commit msg to close the provided bug num) will be **superseeded** when all the tools to manage (first of all: CLI query tool) the 'Change-Id' preudo-header/footer :-D >>> 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. Wow! \O/ > 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. I think that finally we have a clear big picture. Thanks! As stated at the beginning of this message, I'm going to open bug reports :D Happy hacking! Gio' [1] whatever "do" does mean: it could range from a "simple" search with mumi (or something similar) by a human "bug reports gardener" to a full fledged server side git hook to notify involved parties and/or automatically close the related bug report. [2] https://yhetil.org/guix-patches/_/text/help/ =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmUC1ZMMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkS6WMQAORP2yVGzG0R/f9SFEKGvldf3y4ROLm2EumRlmTo o0ahDTnW5mUNiNo6tzJ+vMYdubuTsnFzus3hGdlOp7EGnQeBl/y4V4xG713osneV RfkSHNKwBSk3P+9FqOelnhpzO6FbIjT0ImOgTBMpOpFSwZvDI26EPj3o17tbHnxm jjfv8t1b2IksK223nz1f9hgY/rJ+fiQQ66MxOH5WdlPkxeYTW3ZWiXbowW2yf6o8 idAaPXQy2IvZ5QR+2dzzCu1Ep7HFHpomTBWzfyCc8+f3MFgCJINw6O9UbisXi+PH Dd38A6QPwrUGVei/qh+TlgPuvCfXYutBb6Qfv7RmkCEa4XWtS0eUEZyiR2rw3YbB L5h9qQtcQ3auG5ZGcFxaoKH3hRLdKw3Y/e46y//3O5noRx3nFj6YVDpWWSiVdGSa ooqvSFpoG+I/YVOvmwyVhS9sukj3uaeuWlfGNSvJ5KJPk0m1JElNKu3gKB9pA6zf 3cfOh2EVRI03NAdT2fsRlE14T0Hs/+Z3jGKLmVdU3cWslXaxscMmSIz3N6a6JLWT fgnvUVuhRy551Xkx7tmKf9TnS1EnsdCcWmaBClfrcRa/HtFJOY2tHXnBJ3xlHOKU L3f1MiO+9gA0awAIcEQjDRnHf270iq0mDhwWkRBwoNUJHriXelQe4oGp84uZgDDB WSZ2 =OWAV -----END PGP SIGNATURE----- --=-=-=--