From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 6E7XI2D+M2X81wAA9RJhRA:P1 (envelope-from ) for ; Sat, 21 Oct 2023 18:37:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 6E7XI2D+M2X81wAA9RJhRA (envelope-from ) for ; Sat, 21 Oct 2023 18:37:52 +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 093EE63C40 for ; Sat, 21 Oct 2023 18:37:51 +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-Seal: i=1; s=key1; d=yhetil.org; t=1697906272; a=rsa-sha256; cv=none; b=h2/NnVliT7st1hFFBmy0f45skMsRvVzoozpEEZ/C8cSLb2gJUl+zCB7lKNyU7EwBaHiDs+ AKQdYQTf4REqBECcJNOIvzCRFwOdxSjWiL2dv53gTDGaNKSwSQVrSCR+Y1ptwgbFEakQgX liFBXcNxN2UzJpye9iYsUj/lgmsfpMKuhZpIP3iE/u24YtzEYbxecNqaxbO2YWY9C8PrxO Jp3DNTVljYol85aIgWdVxj1Upv7o6QYO2pfcTC70ypr4XZyBB2BaaER5OGvCup80ousUFH mjpXJIu5hRSHB/qPRVx4Kwex4AqBOwbcLhQXL3XbbsPrJI2Fgapq37wqPMYJHw== 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1697906272; 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=jmOAMJ75G1F/eLelM26Pr6w31jIISA7YlgtkNoRWldo=; b=Guv+3ebZKRSbknqnkE5MfzDvgb5H31PwDXMk1xDWgm13ZPgpbyEObQjAy15tUTv/gGC6Lr 8Cfeb1Ti13TrrJIoQR7y6iXOkwr7Lmnx3ctuljilO/rQQmFiUPTEDzdtdt3G8PVJWGOMbc txuJakGMPEa4zpCSBUMk3F3qNE6MHVjdyCgVfAeZJDdjxcCG6DkUcdrwGsHwXSbxVrQYcx 8rTk1HmxFp9YB0CamaUlta47eVqipzL01A7+nHPchALlaT+8AxpqID4UTZEAILaizssy9P I7f/X12jMbCSLOgduJUuw9aoksQZkbEnYNbdVI2LxUNQQ0X0wiNC4nOOymtrPQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quEyX-0006Ln-Bc; Sat, 21 Oct 2023 12:37:21 -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 1quEyW-0006Lf-14 for guix-devel@gnu.org; Sat, 21 Oct 2023 12:37:20 -0400 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quEyT-0008TP-JJ for guix-devel@gnu.org; Sat, 21 Oct 2023 12:37:19 -0400 Received: from localhost (unknown [217.155.61.229]) by mira.cbaines.net (Postfix) with ESMTPSA id 8702C27BBE2; Sat, 21 Oct 2023 17:37:13 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 82dc4227; Sat, 21 Oct 2023 16:37:12 +0000 (UTC) References: <4c2f6851dece004152bb1904c8b03c7d5206eeeb.1695074290.git.vivien@planete-kraus.eu> <87cyyew4g8.fsf@cbaines.net> User-agent: mu4e 1.10.5; emacs 28.2 From: Christopher Baines To: Vivien Kraus Cc: guix-devel@gnu.org Subject: Re: [PATCH qa-frontpage] Apply incoming patches onto the correct feature branch Date: Sat, 21 Oct 2023 17:35:21 +0100 In-reply-to: <87cyyew4g8.fsf@cbaines.net> Message-ID: <874jik3paj.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27; envelope-from=mail@cbaines.net; helo=mira.cbaines.net 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_PASS=-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: mx1.migadu.com X-Migadu-Spam-Score: -8.25 X-Spam-Score: -8.25 X-Migadu-Queue-Id: 093EE63C40 X-TUID: /Hg3DAHzvu3O --=-=-= Content-Type: text/plain Christopher Baines writes: > Vivien Kraus writes: > >> It seems that the only available information of the feature branch is >> in the patch name. >> --- >> >> Hello guix! >> >> Thank you for making the QA tool. It seems to me that feature branches >> are ignored for patches. The patches seem to always be applied on top >> of master. I get that idea because the base-for-issue-* tag is always >> put on HEAD, and all my patches targetting gnome-team recently get >> applied to master. I understand that the latter could be a problem >> with me. >> >> If patches are indeed applied on top of master, then the question >> arises, what to do. The available information from patchwork is >> scarce: the base-commit is not available, and the optional feature >> branch only appears in the name of the patches of the series. >> >> I think it is possible to parse the patch names. This way, we get some >> useful information: the feature branch, the series revision, and the >> patch index. The patch index can be used to make sure the patches are >> in correct order (this can be the case if a server in the path >> re-orders the emails). >> >> What do you think? > > Hi Vivien, > > Thanks for trying to implement this and sending a patch, I think it's a > good feature to add but there's a few things needed to make this work. > > Firstly, you need to actually change which branch the patch is applied > to, and the place to do that is here [1] in the call to > with-git-worktree. You can probably use get-commit from > (guix-qa-frontpage git-repository) to find the commit hash for a > branch. You'll also probably need to move around some of the code in > create-branch-for-issue so that you have the data about the patches to > work out what the desired branch is before you call with-git-worktree. > > 1: https://git.cbaines.net/guix/qa-frontpage/tree/guix-qa-frontpage/manage-patch-branches.scm#n250 > > The second thing is that there's other places in the codebase that > assume the patches have been applied to the master branch. In > start-manage-patch-branches-thread, there's > get-changes-compared-to-master which is used to decide if a branch needs > recreating if there's too many changes between the base revision and a > recent master branch revision. That'll need changing to at least skip > over any patches been applied to a non-master branch, or perform the > comparison against the tip of the relevant branch. > > The third thing that will need to change to allow this to happen is > adding clear messaging on to the issue page to indicate where patches > have been applied to non-master branches. That'll help to avoid people > merging these patches in to the master branch rather than the branch > they were intended for. > > Maybe what would be helpful is a procedure in (guix-qa-frontpage issue) > that takes the data for the issue from latest-patchwork-series-by-issue, > and gives you back the branch name that the patches should be applied > to. That can then be used to get the branch information for all the > above 3 use cases. > > As for trying to order the patches, do you know of a case where the > ordering from Patchwork is wrong? I think it's only worth changing the > ordering in the qa-frontpage if we know we're doing it for a reason. > > There's now a create-issue-branch command to the guix-qa-frontpage > script as well, which will be a good way of testing the code out for > applying patches to various branches. It'll fail when it comes to > pushing the branch, but it'll still be useful for testing the code up to > that point. > > Would you be able to look at sending some revised patches? I've now gone ahead and applied a slimmed down version of this patch, and made the other changes to get a basic form of applying patches to specific branches in place. There's probably going to be some problems and more error handling to add, but this should be a good starting point. Thanks, Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmUz/jRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XfFWA//eQlBVzdIQZU+Kq/tUhswA7mtwOBllxQV SgFre2jyStNoWjNq2nmDKam2FKOPA03eRxpfwoHSCvgfCai6dttjFeiib7T0amP6 +luiY6Oc+E+WaBnVlyWbrmTDwCq9MvhaiKWwWNGUq7MKEhp3ykcf4qw1+BJ7vlt3 +yztmaCkOGI1CVqc7PmPs+IJZNkLhbL3kV+9ILySfshsKTYODmKND7noi91RJre6 dx90thSKxckKv+Pzilcjf+DVMZkzhf9vVWeQa37VtwIUD7Uvr950BbkthY7DNa5e 61ZrWjd0GIVzmlYOHi2ieQkrHFPK2vofFu2S65sgZJCXB1M0PpJ0K2yUIZWx9uRB NApgURtA9cI3roCkvMlYEVwlMjcaVvNjTpHsgDP2e+gQgy5gPwYcnDeyyocVwDUi dXD3MxvosKLtTEIKJD/kjDKiLNSOsppyx7KklOYXodxmWCb1P5ZccKldlhMdG4qd +6M3L9js4RFnXBPxiwl72FTrT3nmn65FwbE7ecljmLLn8JflF/mwpZWzKF7YVdWf HNIaTzlIKBja38pMDQKzSo2icITMmyfykoBlfXqrcZBXMIqBcHoFBMgdpR+MaFdj nbISDs9QiIbKtuvqCXctCanAnWRb0KfUQKcdEo2Wf/hl7Zi+uGMpv6VGHqNPOeXa 7o/72zEheHw= =YTZu -----END PGP SIGNATURE----- --=-=-=--