From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 OPxTCRSa+WSBpwAA9RJhRA:P1 (envelope-from ) for ; Thu, 07 Sep 2023 11:38:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id OPxTCRSa+WSBpwAA9RJhRA (envelope-from ) for ; Thu, 07 Sep 2023 11:38:28 +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 A4DE054438 for ; Thu, 7 Sep 2023 11:38:27 +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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694079508; 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:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=2ZxX8TAPfpGy5CXtJTJngBT/KgOrbu5t9twl7nGH9UE=; b=Yx5a14tFrBritbSc4YUX2mZ9vDVdN8bDDC+1+MUVGCqOn3I0TSyBYA4c0FZm2H2aoEPgM+ WcRP4QLlm14eXnqR2kV0fOVTV14JQOugKLXZiqa5FS1u3zL6CqdMIqQJu1aklpu6AkppL9 ZbhBnsksk5x6lFL6B7wmubWlq4IT3/kXG+9viVr4Rl6FHnE04OA6Y5oSJw5xRj/ahbcXpb OKXISRbCugedLNa4d9Nn+XQ9YQrhQ0T61yXPy9J1zv90nTgGc2pDg9cBqe2flnt+T6EmpQ 0xlXEIHeIK6JlhMls3qPyDU+c98jtUd6pcUVaFJyP3+1o9uMO4H8YaWFf7qouA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694079508; a=rsa-sha256; cv=none; b=MWslyloiqjgwa9g58fC8zV/7k/DimPX8ulMBN3FbGo66iFjZjxdNxn2aBo6CcncIyBUsYC VIem5iOCI+aHf+02Q3gBLx8+ANdGJ2nxFp87Z1oOj5+yoUinjodEQ5aH5dNEkVFm7FxSiC AOrhREs2nvp4gyNZksf+T5fPVbojAwnaNi7Yju0iFyB2WcAFkhTrNgKRk78Kmijb4dHsOR sUvzShNCoOMqri8L+MRd0cjPyqMEN5tzGlj/2eerSjUkVtsM4sEPhZgINTAAZ3vPHLMoYI ocq9IlgXtznid3/csgYRYzlpENX/vgPdAbJqWUbIecDNt8ZjUZWF5ByxBc0vmg== 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 1qeBSm-0005DD-In; Thu, 07 Sep 2023 05:38:12 -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 1qeBSl-0005Cy-Bn for guix-devel@gnu.org; Thu, 07 Sep 2023 05:38:11 -0400 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qeBSi-0007QM-8q for guix-devel@gnu.org; Thu, 07 Sep 2023 05:38:11 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 733DE3007EC; Thu, 7 Sep 2023 09:38:04 +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 5BMhBgolfY8X; Thu, 7 Sep 2023 09:38:02 +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 284B030022E; Thu, 7 Sep 2023 09:38:02 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id BDCB3298C98D; Thu, 7 Sep 2023 11:38:01 +0200 (CEST) Received: (nullmailer pid 31483 invoked by uid 1000); Thu, 07 Sep 2023 09:38:01 -0000 From: Giovanni Biscuolo To: Christopher Baines Cc: Vagrant Cascadian , guix-devel@gnu.org Subject: [workflow] Triaging issues (was Automatically close bug report when a patch is committed) Organization: Xelera.eu References: <8734zrn1sc.fsf@xelera.eu> <87sf7rbowv.fsf@cbaines.net> Date: Thu, 07 Sep 2023 11:38:00 +0200 Message-ID: <87msxyfhmv.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx2.migadu.com X-Spam-Score: -8.32 X-Migadu-Queue-Id: A4DE054438 X-Migadu-Spam-Score: -8.32 X-TUID: r0ZkPhAb9fny --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christopher, [note: I'm deleting the "In-Reply-To:" header and changing subject to try to start a new thread] Christopher Baines writes: > Giovanni Biscuolo writes: [...] >> 20 bugs with messages similar to this one: >> >> >> rofi-wayland was added in: >> >> 04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland. >> >> And updated to a newer version in: >> >> 19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 1= .7.5+wayland2. >> >> Marking as done. >> >> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/) >> >> IMO we need a way automatically close this kind of bug reports... or am >> I missing something? > > I think the example you give doesn't relate to what you're looking at > below (a post-receive hook). Oh I see, thanks! This is a complex case (see below), at least not one that can be solved by automatically closing bug reports upon commits :-O Sorry for the confusion I added by pointing out the wrong example, a quick look at many bug reports made by Vagrant Cascadian last Fri and Sat shows that many (all?) of the closed bug reports was some sort of "duplication" of others. Vagrant please can you tell us? Let's call this a "triaging issue" and is a class of "management issue" that should be discussed in a separate thread (this one), to stay focused on the subject. Probably missing to "manually" close bugs after a patch set has been committed is not /the worst/ management issue currently, but IMO it's better to just "commit and forget it" :-) Probably /triaging/ is one of the most critical bug report management issue, it should be addressed properly: =2D by finding or developing triage helping tools to automate what is possible =20=20 =2D by having more people do the (boring) task of triaging bugs Probably we should consider adding one more contributor "level": the triager; the triager is _not_ a reviewer (obviously not a committer), even if she could /also/ be a reviewer and/or committer. The point is that triaging is a (boring) activity that Someone=E2=84=A2 sho= uld perform, sooner or later (as Vagrant did with the bug reports mentioned above). Obviously a contrubutor could (should) also be a self-triager, if she wants help making the review process more efficient. > There were at least two different issues with patches for adding > rofi-wayland [1] and [2]. > > 1: https://issues.guix.gnu.org/53717 This was to add (version "1.7.3+wayland1") and AFAIU was never committed > 2: https://issues.guix.gnu.org/59241 This issue have 2 patches: [PATCH 1/2] gnu: rofi: Update to 1.7.5. [PATCH 2/2] gnu: Add rofi-wayland. A (self-)triager should have noted two problems in that patch set submisison: 1. patch contains two set of unrelated changes (?) Point 12. of the "check list" in 22.6 Submitting Patches https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html s= ays: =2D-8<---------------cut here---------------start------------->8--- Verify that your patch contains only one set of related changes. Bundling u= nrelated changes together makes reviewing harder and slower. Examples of unrelated changes include the addition of several packages, or = a package update along with fixes to that package. =2D-8<---------------cut here---------------end--------------->8--- Is the addition of rofi-wayland related to the upgrade of rofi? ...probably yes, but... 2. multiple patches without cover letter https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.ht= ml#Multiple-Patches-1 =2D-8<---------------cut here---------------start------------->8--- When sending a series of patches, it=E2=80=99s best to send a Git =E2=80=9C= cover letter=E2=80=9D first, to give reviewers an overview of the patch ser= ies. =2D-8<---------------cut here---------------end--------------->8--- Missing a cover letter means that triaging is harder. The issue title is from the first patch (gnu: rofi: Update to 1.7.5.) and IMO is somewhat confusing because the title is what appears in search results (Mumi, Debbugs, Emacs Debbugs). If the contrubutor sent a cover letter with subject "gnu: Update rofi and Add rofi-wayland (inherinting)", possibly with a little bit of explanation in the message body, the (now undone) early triaging would have been easier. How do we solve such bug management class of problems? WDYT? > One improvement I can think of here is that QA should highlight that > some of the changes in each of those patch series can be found in > another patch series. ...and tag both bugs as related on Debbugs? This would be very helful for triagers, a very helping tool. ...but we need triagers, IMO > That would then make it easier to both issues to be closed if that's > appropriate. I guess you mean that a (human) triager can find related bugs with the help of such a tool. I doubt that related issues should be closed without human intervention, false positives are very dangerous in this case. WDYT? Thanks! Gio' =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmT5mfgMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkS5fcQALswhkL1E/i9VUlRAlQCxjbVgS9fa1mr31qjqtW9 9K872OKT5B7CNNdvsu2M5xbD2MLiDjJYHnyJHNEbjRXs1yh3/BXc2Pm6xioLfolk Ypq4ufsg5eg/BhazpDe0Rwbtk7ls6gtopirj0WobNTaaf4HCLeYrZDjUX5MX32Ng jqSkCExuF9xNHchp0M0mUgNvttJRG3Dur2sQhGUAFPW6puk1cO2QVwiYTSt4WJrn Ah4NsdFiLU6HJ0gfKHg8aE46G4em9LFb3eY6HTWfhM+UBmcXyJvwiiH38aQgtH/u 59WPbmOc6A+Ywi8HUO1xg0wE+r9WLUmw2c5/BFdnZGZLz2Yrw7tYwRu2KE6DuZ88 CQCk5yUQac1NfkWUYT+teU1k38GaUJoMh78I1IbuSEPPg73QpPZzC/wTf7bSqQlQ NS2zAUJQ11FrkJZchEmFZJuC1lhDPDehXAPXur3gbqPGHtoRZR8Bi/p98f9hwtCM Kyo5N+w0dF8ICQvP32NT9f6MYqLM4LUniAylG4m3RKT5oms1K4CBzet+rIdf13EW Z2RpFn1ujo1KtRwpJmqrMlbaTpyRCX94+aJdSZv3f5UPqRukKDF/mk6LwRLdchjZ 3KbfwjWRfZnYm3/or8p1nS3/sKa1yinn8Mcko4QrQVoXULYLOuV92VbOs9yDPX0w MIPv =QXAt -----END PGP SIGNATURE----- --=-=-=--