From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id WDwtApIDC2GDjwAAgWs5BA (envelope-from ) for ; Wed, 04 Aug 2021 23:16:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GEBpOZEDC2HRTgAAbx9fmQ (envelope-from ) for ; Wed, 04 Aug 2021 21:16:01 +0000 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 301F118F5C for ; Wed, 4 Aug 2021 23:16:01 +0200 (CEST) Received: from localhost ([::1]:37650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBOF6-0001GS-7L for larch@yhetil.org; Wed, 04 Aug 2021 17:16:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBOEw-0001FK-6T for guix-devel@gnu.org; Wed, 04 Aug 2021 17:15:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45098) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBOEu-0000lm-1n; Wed, 04 Aug 2021 17:15:48 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=45360 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBOEj-000399-Oy; Wed, 04 Aug 2021 17:15:47 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Christopher Baines Subject: Re: Project direction with testing changes (branches and patches) References: <87bl6hbd05.fsf@cbaines.net> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 Thermidor an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 04 Aug 2021 23:15:35 +0200 In-Reply-To: <87bl6hbd05.fsf@cbaines.net> (Christopher Baines's message of "Sun, 01 Aug 2021 12:50:02 +0100") Message-ID: <87a6lwoqrs.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, guix-maintainers@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1628111761; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=ufi2qmgeQR1DtkhniVf45fy4nLcOI1SA6EjlEQ47eGw=; b=Pe3pM+KvVigUvrvIdoF07EColZRVExEsIIykb3rYmOIdFBLjozE1OPg1CK6UrHYWQ3PO+s 54PYBOkD15EjsvP4nmxgi8blacPRAC9qwjIdZeJwiEFutgDLDVOiaUhpuIPNeybHFRbyIj ewg7/fpm0QVvBCUkLDsj7LL+0QSwabDUP9cMqxw4G0Waw3B0i1eA2uc4h5zf0m03GSTP+h CUtxxOGOS9Ta6npE/zF9TavWa2arhl4iNYI1vSVvcJRfs2XxqNqJzlxCV3CVtQEUiykROW M9bZyciDNeuRkWGUnAcJvX8Qk2R18aUiggpFU2B3+x1PicoRK0mShB6zlejy6w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1628111761; a=rsa-sha256; cv=none; b=DjRyOk28uEAqxI/RcHOKy1za7UZLzYGWFqEPk9Dlvpb7V1ZtdjCA31Wxv+GwnUxLEdzAvs 0FpoBac38Ynmumq+a3UvyYXKUnxIJg+tQM4amRQAPT9LpMvc9pXusogFPtbiWI5KpJT0Ms z6sab9XoZtpMw0OjPbv9SPCpvnn9LkhTduiVDX3UzKpYo427wcNf7z7cYhyS0LwJ9vGqt1 eqVkyoii4RemxHGbxst5xoVECCAbOPUlydYM+wcgWT24WakL1i/RmUuhVht98X/6a3W+wJ yovelkUVT9Jt80UacAkGfKzJwgJzZR2OJYgEkD0UXFTYDCbLcXjHgWUm5GYHOg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -2.91 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 301F118F5C X-Spam-Score: -2.91 X-Migadu-Scanner: scn0.migadu.com X-TUID: JPkr9N/DoqNm Hello! Christopher Baines skribis: > So, I think I've recently switched to thinking about the problem as one > of testing changes, rather than just testing patches. Since both patch > series, and branches are used to propose changes, I think this makes > sense. > > In abstract, when testing a change, I would break down the problem as > follows: > > - You need to work out what's affected by the change, so that you can > assess the impact > > - Once you know what's effected, you can then build those > packages/system tests/... and compare the build statuses and outputs > against some baseline > > - Then there's the general UI component, ideally a first time > contributor would be able to take advantage of automatic feedback > about a patch they submit. There's multiple other groups of users > though, like patch reviewers, and committers for example. Makes sense to me. I agree that the first problem, seeing what=E2=80=99s affected by a change,= is solved, but it=E2=80=99s still hard to get that info. I think we could hav= e a special =E2=80=9Cskin=E2=80=9D for the Guix Data Service to make it easier = for people to view specifically this information. IMO the current UI has the upside that it=E2=80=99s generic and exposes all the available information, but it= has the downside that it=E2=80=99s generic and exposes all the available information. :-) Or we could extend Julien=E2=80=99s Gitile=C2=B9 to include links from comm= its to lists of changed packages. The UI doesn=E2=80=99t have to be a web UI actually; we could use the Data Service client interface at and write a new CLI, Emacs mode (similar to =E2=80=98M-x build-farm=E2=80= =99), or something. =C2=B9 https://git.lepiller.eu/gitile > I think the first two sub-problems are effectively solved. The Guix Data > Service is able to determine the changes between two revisions (assuming > it's processed them). The Guix Build Coordinator can then be used to > build the relevant packages/system tests, and report that information > back to the Guix Data Service. > > The UI part is much less certain, I've done some work with Patchwork, > and I do have some ideas in mind, but there's still more thinking and > work to do in this area. > > Before pressing on though, I think it would be good to know if this is a > viable direction? I think we desperately need more automation, even more than when you started working on this! I think a first step could be to make info from the Guix Data Service more readily available, as suggested above. And from there we could address #2 and #3. The Patchwork instance you maintain at does a large part of what we want, though the UI is not my favorite I must say. ;-) I wonder if we could again make minimal changes to Mumi so that it includes links to the relevant bits at the Data Service. That=E2=80=99d make it more readily available. WDYT? > Currently, there's no automated testing of patches, and testing of > branches is limited to the information that Cuirass provides on failed > builds. What I'm proposing for the future is: using the Guix Data > Service together with the Guix Build Coordinator to analyse the effects > of changes, whether that be from a patch series or a branch. I realise > that I've already been experimenting with this, what I'm mostly > referring to here is moving towards this being the documented approach, > maintained by the project, not just me. >From an administrative standpoint, I very much agree that this sort of infrastructure should be financially supported by the project rather than by an individual, and documented so we can maintain it collectively. Of course that involves a bit of overhead, and sometimes we=E2=80=99re not all responsive when it comes to paperwork or sysadmin (pe= rhaps these are not our preferred activities?), but still, it makes sense to build that collectively. That=E2=80=99s my take. Thanks for the update! Ludo=E2=80=99.