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 QLiKBDs192RWYQAA9RJhRA:P1 (envelope-from ) for ; Tue, 05 Sep 2023 16:03:39 +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 QLiKBDs192RWYQAA9RJhRA (envelope-from ) for ; Tue, 05 Sep 2023 16:03:39 +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 6732151A1F for ; Tue, 5 Sep 2023 16:03:04 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=saWQMo13; 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=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693922584; 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:dkim-signature; bh=TbcD0vmkGFtst6alQvpQqPkNt9fcmaknTtL23H9uuug=; b=cPWXwgn8taIaPUdCYfyZJNPd5Qg15ur3/YQHuWb9KaChPIhVh5DosKK6OyWJkbzAvsaBG+ 5+ZP+fi9yg5xZ68paX6dcDd5xXV5Tkvum5aPJk5afhThfsREgVnsyTOryXf/7liGYjp2CV QOYTiURWPqHFx+4Q/TLEDpjeVjwnL2IJjFxVYg2McBhp5+NAYHBttSkQPZHBEPcBAcyqID A4fOx46Cle3soQmEgABRoCAuukzGueyAk9KKPznxK9ai1Kj6bGIj/isy8EKEVAIN2cXT5d D9OILEubmRH3rj5cSzN3j+pWsQObB+2/JLJPI++g6dGzkHb+cidxCmUF2dOEsA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693922584; a=rsa-sha256; cv=none; b=mbYcdHmIhKDrcGE6OoV+SNSUr5YOWrE1J1rz4bA3zkN6qMkM6WMIinC4zMxBlUmXSe+ZfZ ZI11Uo/F7f5+r8VZSZsUy5MfGLgiM6wDR44JIe+PXKL4il5HvHC7eR28+Z8WxuBtbx/4g0 yIvxiDeDtfRGe2xlfirV8hTi/0+W2Cw6UmVXPywiD1wPyrK2LKV0bOjX8ycOKpAkpKifPH c20vKhSA+TKvMYst5UzZgp5SrvoBEeAnh6553r4HUcjDfdm8X2GlmIELlvPoNQ0XdRMH6L aJHW8Nx/7/7YGshGY8NNRCgzepAZ64Aa5KmRdWIlCxoktLHHWrbTzr3AKNAjrA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=saWQMo13; 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=pass (policy=none) header.from=gmail.com Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdWd4-0002ay-NH; Tue, 05 Sep 2023 10:02:06 -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 1qdWd3-0002aa-K5 for guix-devel@gnu.org; Tue, 05 Sep 2023 10:02:05 -0400 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qdWcz-0003hS-42 for guix-devel@gnu.org; Tue, 05 Sep 2023 10:02:05 -0400 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-31985ebed68so162170f8f.0 for ; Tue, 05 Sep 2023 07:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693922519; x=1694527319; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=TbcD0vmkGFtst6alQvpQqPkNt9fcmaknTtL23H9uuug=; b=saWQMo13P3kXGcfkOZVexSyT8uUQNEf/noD+2NNbmHlYiZSv38crJCVY2J6tz/ilt3 n1SNf+KRYcPZ6YcK46qloq3w+50M1DMa3SDEfKpt4UMYw4wZDTwBRWTvGAniuMD+tdFi mPmh6dg3YKbDC2f6o0GKJFoVMjIz9b5wVQ8rjBVn3k/lg0vEMNiUP1ih//LY2iIK3vN/ duCDLdmmdj+8KdJVtsJq8peTEmyhZRZmzR/8syde83LhPaJLNQ5EgvDRmBHD2EqNVrEM RKitxmqNqb2ld9g7DaI4KPCw5a6tdgB2ifIRQC21hmnQFrTs1ca+eTqSiTlnX0shrIL2 L2zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693922519; x=1694527319; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TbcD0vmkGFtst6alQvpQqPkNt9fcmaknTtL23H9uuug=; b=PZ9yHJORiBXlGijuDFAttGiKn2jaGBRc0HD4fUN4EmwtNQTK/ABBGCzhSDShzOoKdw lldoBn+Rpr0ibxHayTJh6f+AUGvpbUgfmrXTb61FgYcPPVtzU3teTJiwJKNongqXEdwM RC0xFcutff5XcVJzmGlzIfBMjkbishlj3bn9JQ1Hn0LYxa0nk3WFX8bS0s7H41WXLLZS o732QwJF+XWrYW/aczr3Nof1bc41PI6q7R/bzPgFOM8bOm1PrV0atCWGFEcXMsBh/0Lx rHIZMpGJMo1D85XLXqsIUoe5y/17P7JldwRXr6OiWtcdNE923c+oR7vtcHXRn4AWvkGj hYeQ== X-Gm-Message-State: AOJu0YyZyuTywW88JWU3Y4arqUOMnOtnp5X2YQ/FvDQETIhbgMhhNH9t MhfqwVoSPsZ21Py3FxmSY/E= X-Google-Smtp-Source: AGHT+IHRGXE1udJCQmDzqUUcqp+a6YzlAGIJl/UiGY77dfxBiIj3IQXsKDxKReWzttcm0o4rOzCy5Q== X-Received: by 2002:adf:e745:0:b0:31a:ed75:75d4 with SMTP id c5-20020adfe745000000b0031aed7575d4mr8580651wrn.2.1693922519290; Tue, 05 Sep 2023 07:01:59 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id a16-20020adfe5d0000000b003179b3fd837sm17710740wrn.33.2023.09.05.07.01.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Sep 2023 07:01:59 -0700 (PDT) From: Simon Tournier To: Katherine Cox-Buday , guix-devel Cc: Vagrant Cascadian Subject: Re: How can we decrease the cognitive overhead for contributors? In-Reply-To: References: <871qfsuvad.fsf@gmail.com> <8e74c4ac-a6f3-9127-7e13-593a2eb70432@gmail.com> <87a5ubqxm6.fsf@gmail.com> Date: Tue, 05 Sep 2023 16:01:17 +0200 Message-ID: <861qfcvhw2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x42f.google.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: -5.59 X-Migadu-Queue-Id: 6732151A1F X-Migadu-Spam-Score: -5.59 X-TUID: 7hzsja06svNK Hi Katherine, Thank you for your extensive analysis. I concur. On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday wrote: > 3. We should reify a way for Guix, the project, to measure, and track=20 > progress, > =C2=A0=C2=A0 against long-term goals. Particularly when they're social a= nd not=20 > strictly > =C2=A0=C2=A0 technical. That is the most difficult part, IMHO. Well, what are the long-term goals? :-) I am almost sure we will get various answers depending on people. Let say the long-term goals of the Guix project are: Liberating, Dependable and Hackable. Then how do you give concrete quantities that we can measure or track? And it is always difficult, if not impossible, to measure or track some goals that are not technical but social. For example, how do you measure being welcoming or being a safe place for all? Do not take me wrong, I strongly think we must think again and again on that point for improving. It=E2=80=99s just easier to tackle technical bug= . :-) > =C2=A0 11. Try and get each commit message close to correct and commit. > I view steps 1-10 as pretty standard "development" steps common to most > projects, although 11 compounds the effort in 10. Maybe I am doing incorrectly but I have never thought much about that. For that point #11, from my point of view, it is as with any other project. I start by running =E2=80=9Cgit log --grep=3D=E2=80=9D for gettin= g inspiration. Well, as a rule of thumb, I am doing something like: --8<---------------cut here---------------start------------->8--- top-module: submodule: one line summary. Fixes . Reported by Jane Doe * path/to/file.scm (variable):[sub-part]: Description of the change. [otherpart]: Other description. * path/to/other/file.scm (other-variable): Description. --8<---------------cut here---------------end--------------->8--- In case of doubt, I am just running =E2=80=9Cgit log --grep=3D=E2=80=9D loo= king for similar thing, as said. :-) > =C2=A0 12. Run `guix lint` > =C2=A0 13. Run `guix style` (this is still in the manual although I have= since > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 learned this is not actually advisable). > =C2=A0 14. Review the changes these tools have made, and fix things. > =C2=A0 15. Run `guix build --rounds=3D2 ` to check for idempote= ncy. > =C2=A0 16. Run `make` to ensure you didn't break anything elsewhere in G= uix. > =C2=A0 17. Run `guix size` to ensure the closure isn't becoming bloated. > =C2=A0 18. Build all the packages that depend on this package. > =C2=A0 19. Run `guix pull --url=3D/path/to/your/checkout=20 > --profile=3D/tmp/guix.master` to > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ensure you didn't break Guix in a differe= nt way. > In other projects I've worked with, steps 12-19 are commonly done in a CI > pipeline, and courteous people will try to save CI resources by running=20 > these > steps locally first using some kind of environment identical to what CI r= uns > (sometimes a container is used for this. I think Guix has better options!= ). > Sometimes this is not feasible due to asymmetric resources. But having the > option to let CI manage this process is very nice. For instance, I am not seeing =E2=80=9Cmake check=E2=80=9D. ;-) And that o= mission makes very clear the cognitive overhead we are speaking about! Here I see two annoyances: 1. The number of subcommands and steps. 2. Each subcommand has a list of options to digest. Well, CI is helpful here, for sure. However, it would be helpful to have a script similar as etc/teams.scm or etc/committer.scm that would help to run all these steps. It does not mean that all these steps need to be run before each submission. However having a tool would help irregular contributors or newcomers; it would decrease the cognitive overhead i.e., that overhead would be pushed to some script and it would reinforce confidence. Now someone=E2=84=A2 needs to implement this script. ;-) > =C2=A0 20. Run `git format-patch -1 --cover-letter [--reroll-count]` > =C2=A0 21. Run `./pre-inst-env ./etc/teams.scm cc-members ` to ge= t=20 > the CC flags for Git > =C2=A0 22. Remember that if you're sending multiple patches, an email fi= rst=20 > has to be > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sent to `guix-patches@gnu.org` to get an = ID, and then... > =C2=A0 23. Run `git send-email --to guix-patches ` Well, my grey hair are biasing my opinion. ;-) From my point of view, the most annoying is #22. Vagrant suggested [1] to send patches as attachment. I am not convinced it will be better. Well, it will for submitting but will not for following series. For instance, let consider: [bug#65010] [PATCH 0/8] Misc Python build system improvements Lars-Dominik Braun Wed, 02 Aug 2023 12:37:57 +0200 id:cover.1690972374.git.lars@6xq.net https://issues.guix.gnu.org//65010 https://issues.guix.gnu.org/msgid/cover.1690972374.git.lars@6xq.net https://yhetil.org/guix/cover.1690972374.git.lars@6xq.net then, one will do reply and probably comment one or more patches over the 8. Then, it is harder for another person to follow. For example, I would have to open the message in order to know that this series adds, guix: toml: Add TOML parser. which could be interesting for Julia. And I would probably skip all the series because the subject is about Python build system improvements that I am necessary following. However, if I see the subject, guix: toml: Add TOML parser. then I open the message and read it. Therefore, I do not see any =E2=80=9Cgood=E2=80=9D solution for this point = #22. One idea would be to have a kind of proxy. We would send the whole series to an hypothetical guix-contributions@gnu.org and then a bot would send to guix-patches for getting an ID and that bot would send the series to that ID, probably adding some X-Debbugs-CC for the submitter (and for teams). Bah, too much =E2=80=9Cwould=E2=80=9D. :-) 1: https://yhetil.org/guix/87wmx8m5gb.fsf@wireframe Re: How can we decrease the cognitive overhead for contributors? Vagrant Cascadian Sat, 02 Sep 2023 18:05:40 -0700 id:87wmx8m5gb.fsf@wireframe https://lists.gnu.org/archive/html/guix-devel/2023-09 > If I compare this workflow to the workflow of other contributions I make: > > =C2=A0 1-10 as usual > =C2=A0 11. Write a more commonly accepted commit message with no special= =20 > formatting. This depends on the project and I am not convinced we can rule for #11. BTW, one strong advantage for this commit message format is that grep can be exploited. For some reasons, I am often looking for some past versions, for example, --8<---------------cut here---------------start------------->8--- $ git log --pretty=3D"%h %s" | grep Update | grep vlc 8d342711dd gnu: vlc: Update to 3.0.17.4. 5a29cc9ade gnu: vlc: Update to 3.0.17.3. fb0e5874ec gnu: vlc: Update to 3.0.16. e2ad110f4c gnu: vlc: Update to 3.0.14. def314d810 gnu: vlc: Update to 3.0.12. 6ec120b1c7 gnu: vlc: Update to 3.0.11.1. 0bed485a39 gnu: vlc: Update to 3.0.11. 178f1d1f75 gnu: vlc: Update to 3.0.8. cf40f8e4d7 gnu: vlc: Update to 3.0.7.1. 94f7f9503a gnu: vlc: Update to 3.0.7. dba326def1 gnu: vlc: Update to 3.0.6. ea593fe298 gnu: vlc: Update to 3.0.5. d0e23e3940 gnu: vlc: Update to 3.0.3, and add more inputs. 7627705293 gnu: vlc: Update to 3.0.3, and add more inputs. f137f84923 gnu: vlc: Update to 2.2.8 [fixes CVE-2017-9300, CVE-2017-10699]. dd13aa90d6 gnu: vlc: Update to 2.2.6. 3bc45ad460 gnu: vlc: Update to 2.2.5.1. a134cc8e93 gnu: vlc: Update to 2.2.4 [fixes CVE-2016-5108]. c6c86cd7a5 gnu: vlc: Update input Qt to version 5. 9c55bae607 gnu: vlc: Update to 2.2.1. 1a189da0e7 gnu: vlc: Update to 2.2.0. b9156ccc08 Revert "gnu: vlc: Update to 2.2.0" ad036bda89 gnu: vlc: Update to 2.2.0 23466647a8 gnu: vlc: Update to 2.1.5. --8<---------------cut here---------------end--------------->8--- And because there is some variation with the commit message format, these are not all the updates of VLC, --8<---------------cut here---------------start------------->8--- $ git log --pretty=3D"%h %s" | grep Update | grep VLC af74211d98 gnu: VLC: Update to 3.0.18. 5af110868c gnu: VLC: Update to 3.0.10. 091ef8c97e gnu: VLC: Update to 3.0.4. 324c049ff6 gnu: VLC: Update to 3.0.3-1 [fixes CVE-2018-11529]. --8<---------------cut here---------------end--------------->8--- Then =E2=80=9Cguix time-machine --commit=3Dfb0e5874ec -- shell vlc=E2=80=9D= and hop I get 3.0.16. If the commit message format would not be so strict, this would be impossible and we would need another external tool. > =C2=A0 12. Run `git push` (subsequent changes are still just `git push`). > =C2=A0 13. Go to forge website, click button to open a pull-request. > =C2=A0 14. Wait for CI to tell you if anything is wrong. To be fair, here you forget one important blocker: having an account to the forge website. I do not speak about freedom issues. Just about the fact to open an account to the forge website. For example, let consider this project: https://framagit.org/upt/upt And if I want to contribute with a Merge-Request, I need to open an account to the Gitlab instance of FramaGit and push my code to this instance, even if I already have my fork living on my own Git repository and I have no plan to use this FramaGit forge. > If you're so inclined, for a bit of fun, and as a crude way of simulating > compromised executive functioning, imagine that between each of the=20 > steps above, > a year passes. And reflect on what it would be like to gather the energy = to > start the process of starting a contribution of some kind, let alone=20 > follow it > through to completion. I like this way of thinking because it helps to spot some blockers. Please note that it is not truly about the complexity of the steps but about how many steps one is able to complete between two interruptions. Well, it is a well-known issue about task switching [1]. :-) 1: https://en.wikipedia.org/wiki/Task_switching_(psychology) Cheers, simon