From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 UAGbMW3v+WS2RQAAG6o9tA:P1 (envelope-from ) for ; Thu, 07 Sep 2023 17:42:38 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id UAGbMW3v+WS2RQAAG6o9tA (envelope-from ) for ; Thu, 07 Sep 2023 17:42:37 +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 3B5655770B for ; Thu, 7 Sep 2023 17:42:37 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b=gCZ89jse; 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=1694101357; 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:dkim-signature; bh=c65xoafv5XY5AV+zw04x0lMSKVZzWTdSh2XDhoE1cH8=; b=RNVfKucgVlXnNOo5bYLhxuti+S37VzrnJuM+OINL1lNHn6+oJGSr0Zp5gwLK3KKXli1YR1 33OHMfIK4qrX/2DP6LdXFD+kMqGaykq0u0zJNQ7VN3M3DODCNjmSpP7QqKbyIz3Sz5F3fW fVsesrHpb9N7YaX61LhRX9kXfjCWbWGTcg5IgC6ncHRwwPLnGPBlrBOyf+G18Skb9Davbv r14WxzWL8cJaL+POaxCWXHZ8D4dMoqiHnCd/H3X6ibCVeCGh9Teq1M4rzpFdJTBqVxJS+C ZGmEbM+vNj8XPYS8fQ2s8vGizqwE2YSXQJt0sABjdEu4XgYAOKRHjCZaCDRLVQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694101357; a=rsa-sha256; cv=none; b=LBGke3dGtNEYajghZg3Ly5jt360vTzehYvbkRWZ4cNE717D8Y6edn+9D5QaMO3h0rUIqTt 6yOBJn+gB5HUjLkQVpa97L9zSqCZjrpgQQRwRbE4ogvmnZ6l4ECA0EO4eK6aIBkcpAG7xK Y7T59XwGeEagp6sHubs7YTEApXnT+PYvRtz5+q42DYQdj6AmV8JkV5bhHgo5AU8gZAwVqz TEcgH8YXPom9et7ULEDyKT//quhNlNpY8UBpX+dxY67JJG3BTzjpVnQkf4qKQfDNi3HOqm HRzuP5LGg1sdYqY/CkezyYlWzkKv+7TyqN2eSQ2igldUD06tMpBtKUEUqegYjg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b=gCZ89jse; 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 1qeH8t-0003w0-UX; Thu, 07 Sep 2023 11:42:05 -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 1qeH8l-0003v3-0b for guix-devel@gnu.org; Thu, 07 Sep 2023 11:41:56 -0400 Received: from cascadia.aikidev.net ([2600:3c01:e000:267:0:a171:de7:c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeH8g-00020T-7t for guix-devel@gnu.org; Thu, 07 Sep 2023 11:41:53 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:7:77:0:50]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id 818AA1AD30; Thu, 7 Sep 2023 08:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org; s=1.vagrant.user; t=1694101303; bh=DbCS1bTstYUDM5hLxq3qcFQ1Qxw4WuXpjX499pLKqFw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gCZ89jsepkmQ9qKujT1vCAvZR0JGRu1iC7QAMQq9ej/ajyUoqZ5CxC1SNjrN+HRMm Q5ERCqk4uMvi/Xa4sJ4c9UT4S4VRYTMSkL64QPXHC8o5QJUBN00VcOVVQsCU1lS5Ur K3Gs2OIljJJcoG8TB0kuc2x3hwOLmlmmyoGICS33OjL0OY+S90LBnrv4oE2AEaB4Xr FHiizGqTYtEWLz4KQiP33XfEoc5COcqphcVeRTUz0rf9nMc2nR4QjC5/LNp5Fa8aP3 atgjLnOHJM2EXOipcZYNRQwiCwAHOzhN9hc05eBKnaP5pWZ30n9eHd+iQS0q9J8yWg XN/sqi025Q/JA== From: Vagrant Cascadian To: Giovanni Biscuolo , Christopher Baines Cc: guix-devel@gnu.org Subject: Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed) In-Reply-To: <87msxyfhmv.fsf@xelera.eu> References: <8734zrn1sc.fsf@xelera.eu> <87sf7rbowv.fsf@cbaines.net> <87msxyfhmv.fsf@xelera.eu> Date: Thu, 07 Sep 2023 08:41:36 -0700 Message-ID: <875y4mm1n3.fsf@wireframe> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: none client-ip=2600:3c01:e000:267:0:a171:de7:c; envelope-from=vagrant@debian.org; helo=cascadia.aikidev.net 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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: -9.92 X-Migadu-Queue-Id: 3B5655770B X-Migadu-Spam-Score: -9.92 X-TUID: P8BTcqIbmFUY --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2023-09-07, Giovanni Biscuolo wrote: > 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? Yes, I think a fair amount was from "duplicate" patches. From memory, I would say many, if not most, of the bugs were due to one person submitting a patch, and someone else independently committing the same or newer version. Part of the problem with duplicates may be the difficulty of reviewing a very long poorly curated list of bugs... before issues.guix.gnu.org was a thing, it was difficult to actually find prior submissions... and it is still long enough that it is not easy. > Probably /triaging/ is one of the most critical bug report management > issue, it should be addressed properly: > > - by finding or developing triage helping tools to automate what is > possible >=20=20=20 > - 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 s= hould > perform, sooner or later (as Vagrant did with the bug reports mentioned > above). I was definitely in the mood for "let me get some relatively easy, if boring things done" the other day. :) > Obviously a contrubutor could (should) also be a self-triager, if she > wants help making the review process more efficient. FWIW, I think I used the search: https://issues.guix.gnu.org/search?query=3Dis%3Aopen+tag%3Apatch Sorted by date, and searched for the phrase "update" in the subject, as old bugs proposing to update to a newer version were and are, well, likely candidates for culling. :) Other tooling that could further help with the process would be valuable. >> 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 Right, I marked this (and several others) as done because it was effectively superseded by newer versions in current guix. There were sometimes some things that were not merged, and I made judgement calls on weather they still needed to be, such as a tweak to the packaging that was maybe only needed to get an older version to build, but the newer version was building correctly. >> 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= says: > > --8<---------------cut here---------------start------------->8--- > > Verify that your patch contains only one set of related changes. Bundling= unrelated changes together makes reviewing harder and slower. > > Examples of unrelated changes include the addition of several packages, o= r a package update along with fixes to that package. > > --8<---------------cut here---------------end--------------->8--- That is a good reminder, there was at least one bug that seemed like a collection of "music" packages, and over time more packages were added, even after the original packages in the bug title were merged. > 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.= html#Multiple-Patches-1 > > --8<---------------cut here---------------start------------->8--- > > When sending a series of patches, it=E2=80=99s best to send a Git =E2=80= =9Ccover letter=E2=80=9D first, to give reviewers an overview of the patch = series. > > --8<---------------cut here---------------end--------------->8--- > > Missing a cover letter means that triaging is harder. Indeed. Retitling can be used to help after the fact, at least. > 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). I retitled several bugs as well, to at least update the current status, as a few had some patches merged or superseded, but there were outstanding issues not yet merged. > 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. Yes, cover letters would help significantly with triaging these more complicated cases. That said, sometimes over the course of review, it becomes clear that additional changes are needed, and it would be helpful to retitle the bug in these cases. I saw at least one bug which started out as "Add XYZ" and evolved into "Update ZXY, ... Add ABC, Add XYZ" and it would not have made sense to make them separate patch submissions. > 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? Not sure how to mark related, but bugs can be marked as blocking other bugs... this would make some sense in splitting patch series into multiple bugs, marking blocking bugs for patches that are dependent on others. But I suspect that would be painful in practice in many cases. > 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. With old patches, honestly, it might bring attention back to an issue to close it. When I get a bug closed notification, I definitely check to make sure the issue is actually fixed, or did not introduce other surprises... I am not saying I think we should just blindly close old bugs with patches, but processes that err slightly on the side of closing old ones, perhaps with a message "please verify if the issue is actually closed, and reopen in case we have made a mistake." might be reasonable. Obviously, if an automated process can automatically rebase and it still applies, this might be an indication that it still requires human review and tag it as such... although occasionally a patch might propose adding something to gnu/packages/abc.scm but actually gets merged into gnu/packages/xyz.scm, and this might rebase "fine". live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZPnvMAAKCRDcUY/If5cW qlRWAP49Q3xqhd8DhB0I1oGfQpgb0xVFoKH/LYcWUvck2b7OOwEA5JfZ2cxZwLbR gHRkiY7cCwcWcEpwyasgqEFJwcMXpg4= =SNST -----END PGP SIGNATURE----- --=-=-=--