From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id KH02MxcFBGXUPAEAauVa8A:P1 (envelope-from ) for ; Fri, 15 Sep 2023 09:17:43 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id KH02MxcFBGXUPAEAauVa8A (envelope-from ) for ; Fri, 15 Sep 2023 09:17:43 +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 8E5515CEA1 for ; Fri, 15 Sep 2023 09:17:43 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694762263; a=rsa-sha256; cv=none; b=E6JXKRXwdvie4stpGgkq8pECRrzaXt6wVrGPaws/pexuW4vy/thN9iK3ajCbM5aYkByXxJ gcy9kOcUGTNC326KBg7cJlraCbryotJClqQILw/RTfYbqTIiNEH6BvbE+t4DpbxUmt8ebS HIyyWUahZxIlO2QOWJg0JEX/5LPLdDxCFlSS4FviHlgFAribeet3bI+3fTzQKyb3Ad39g8 sbRqVZLT6sq6wHKgSwU/7TnlPOvJvk4tbGEWaX2/R/dONvvhv+c5UKirpxbhwJa6vKbPHD 0wjStKrum+RlNKtNboI1ioCovUavNGzDvlXTeqfEvkHwuFFISGUs1N6ZWUaWLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694762263; 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=H6i+nddkjr7xxUt+j0Xe5Thp96OGSm1PxcHCJx/3G0U=; b=f23dq6JYvNFkkrhtZDDENpdX9Y2rxNYrEjnespbWRJQXQR2EPg897mE5QecMZPcNwO7mvP 4SKpzNJYwiR5BAAdGXSRD3aj737NzHk+4o9c++ikZm3apDqPbEL09pCz4B8j7E1/aS10+v FqjXe+ogAzw2Jx/frquUJsMEzbxD+jlKurYrf84KQlJhHgTEpVFG5KP3Mo6GYTInf7BeTz X54xQBpL3lPsbU9GpMXOIN3trtT3DUv9DEVEfULY1QJYPCe3zX9wKoP/Nkc4KwhksUwMYF f0/DQUiaj+UNYpieln8yUDnkAdTczZFWqS+mSs8eQG5f2YVHOaOV3TdUrDo0OQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=none Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh34U-0004yJ-Pc; Fri, 15 Sep 2023 03:16:58 -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 1qh34S-0004xp-VU for guix-devel@gnu.org; Fri, 15 Sep 2023 03:16:57 -0400 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh34Q-00046f-67 for guix-devel@gnu.org; Fri, 15 Sep 2023 03:16:56 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 9FF443009C0; Fri, 15 Sep 2023 07:16:51 +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 32TbZy4lHtNT; Fri, 15 Sep 2023 07:16:49 +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 BFA6A30022D; Fri, 15 Sep 2023 07:16:49 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 507B129C7E5B; Fri, 15 Sep 2023 09:16:49 +0200 (CEST) Received: (nullmailer pid 25624 invoked by uid 1000); Fri, 15 Sep 2023 07:16:48 -0000 From: Giovanni Biscuolo To: Simon Tournier Cc: guix-devel@gnu.org Subject: Re: [workflow] Automatically close bug report when a patch is committed In-Reply-To: <877cotdjr2.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> <6929416953b2939445a5247b014142ea8bb521d9.camel@gmail.com> <87h6nyw0su.fsf@gmail.com> <86zg1pwwmw.fsf@gmail.com> <87cyyl9hi7.fsf@xelera.eu> <877cotdjr2.fsf@gmail.com> Date: Fri, 15 Sep 2023 09:16:48 +0200 Message-ID: <87h6nv9a8v.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: -8.31 X-Spam-Score: -8.31 X-Migadu-Queue-Id: 8E5515CEA1 X-Migadu-Scanner: mx2.migadu.com X-TUID: 2RjJO4JDxGhb --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Simon, thank you for havig listed possible troubles. Before commenting, just let me repeat that we are _copying_ the 'Change-Id' idea (and related possible implementation issues) from Gerrit: https://gerrit-review.googlesource.com/Documentation/user-changeid.html This means that Somewhere=E2=84=A2 in our documentation we should start explaining that: =2D-8<---------------cut here---------------start------------->8--- Our code review system needs to identify commits that belong to the same review. For instance, when a proposed patch needs to be modified to address the comments of code reviewers, a second version of that patch can be sent to guix-patches@gnu.org. Our code review system allows attaching those 2 commits to the same change, and relies upon a Change-Id line at the bottom of a commit message to do so. With this Change-Id, our code review system can automatically associate a new version of a patch back to its original review, even across cherry-picks and rebases. =2D-8<---------------cut here---------------end--------------->8--- In other words, 'Change-Id' is /just/ metadata automatically added to help in code review **tracking**, specificcally helping "across cherry-picks and rebases" [1] Sorry if I'm repeating things probably already understood! Simon Tournier writes: [...] >> Please can you expand what troubles do you see in automatically adding >> 'Change-Id:' using a hook-commit-msg like >> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg= .html >> ? > > 1. The hook must be installed. AFAIU a hook is already installed when configuring for contribution. If this is stil not properly documented it will be fixed. > 2. The hook must not be in conflict with user configuration. I guess you mean not in conflict with other locally installed git hooks: since AFAIU we **already** have a locally installed git hook, this is already a requirement and this is something the user (contributor) should be aware of. If this is stil not properly documented it will be fixed. > 3. The generated Change-Id string can be mangled by some user unexpected > action. Contributors and committers should not delete or change and already existing 'Change-Id', this will be documented. > Many things can rail out on user side. For an example, base-commit is > almost appearing systematically in submitted patches almost 3 years > later. I don't understand how this could impact the addition of the patch-tracking metadata named 'Change-Id' > The patches of some submissions are badly formatted. Etc. I don't understand what is the problem of having a 'Change-Id' (in commit messages) in badly formatted patch submissions. > Whatever the implementation, I am not convinced that the effort is worth > the benefits. OK, I'm sorry > And I am not convinced it will help in closing the submissions when > the patches have already been applied. OK, I'm sorry > That=E2=80=99s said, I am not against the proposal. I just have mixed fe= elings > and before deploying I strongly suggest to review if the proposal covers > the intent. OK, thank you for your suggestion. Happy hacking! Gio' [1] AFAIU 'Change-Id' can even track different versions of patches (that by design are from commits in the same branch, properly rebased as needed) sent by mistake via **different bug reports**, this also means that different bug reports containing the same 'Change-Id' are _surely_ linked togheter. =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmUEBOAMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkSqC8P/3YPwk2TC1P18umMwrAK8SqkKBFDz1rtd9BkzirC MY+z/jmMPAem2JpitIXL0D55mJW4OXABJBb8sHwd4EvgGSoLtmy6fsS6B5KYmZTr FxWjeb0rDUb6LXM6kUx/oTjG4WDtqObXmwy/62g6zAiiFhdQS4/XCMyBCRDpjQte +HMDyTuag/WlWkOxq5Apq4bSz8S4O+kDCtjxx2Va+5o2rjyWzPh99dCeRxTQLZF8 oPPJNdxGjAJOc6M39KVD+nPFhUoH4WQ4VFl3BbqHB4FZOdreKu+RR7ko2Mv84K6u o7zAftci/xDV9L81BsVD5l4b/q205KoPivTm9Ti6tovpijao/Yt2IhvwNB3MlhmV 9rhnZFFccnkG4zo8mX1M37bLnNyjQuaXugSGzOxxkjzoY+ainVkCOLj+F8EE3C7m tsi2wN2JZArvNp1fVwxHfOiRL47UeUo4VgOVbAFFbyxOPz3fpgsQUIpAjZQQds8n o/DLW3Z3DhCDDByEBx/0Nh+cajrjNGwO8ZBzZahJhqk+UTS3wSRpsrGr5eCJkemF NV/LuEFwHD7kcxPeSy05nS83c+b1yv4q9SeKTIqtXgU3Wy0nK7Z3ov+7+Avt3BQ6 Ka3MeuHx3H/LlE9ltNoA3XA7PV+ibl4UJFxyiSQhO0qymVKRNDjlYLWOu2yisdAR ViH7 =Lw+g -----END PGP SIGNATURE----- --=-=-=--