From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id QIXzKCTBAWVHCQEAauVa8A:P1 (envelope-from ) for ; Wed, 13 Sep 2023 16:03:16 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id QIXzKCTBAWVHCQEAauVa8A (envelope-from ) for ; Wed, 13 Sep 2023 16:03:16 +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 8C1973C071 for ; Wed, 13 Sep 2023 16:03:10 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=msavoritias.me header.s=20210930 header.b="P0GA/F/G"; 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=fail reason="SPF not aligned (relaxed)" header.from=msavoritias.me (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694613790; 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=5yaF00NPS9X0TqFqiBcmLb3WOl8+pxEp6IZeB35+Phw=; b=KbvyCXk086PbRPgUn2xQuVnYceiZgs2WonZFBaEg4AMEdd1oHQl8WLP3q4OEAglYJUEwcq gH/AMQkzyqQ3ttvtuEh9pT8q3DIoKGag7g1ll32t92VgQ0gtgSTgzemBOzOlCln/eHU2zd lEoJ9nKD2SS7Ul4QHZIRjRiIAU9yDct686yH3G2rcuQt5NpcS0ztR81w2VCVDM7Tg1+77t DUWo3CsgPIQZKFiRWAyVQA2tiSq8IxDbTGjJiXdNpLRGmGHJQL5prMnzcwFKlmtbM0HByK ZmGAAjbjPkB2kqnhfr8hQaeGk04rAusCnbyLjQQ3Yank3PWGZY8eQpAHixSx4Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=msavoritias.me header.s=20210930 header.b="P0GA/F/G"; 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=fail reason="SPF not aligned (relaxed)" header.from=msavoritias.me (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694613790; a=rsa-sha256; cv=none; b=Q6h3ycKDbzi7eKqZg0nr7urxr5LdKluV7ZmkgLuBpUAQHPDAcKiDBA8rl1Nv5yvJlm9k2J w8tQhIQel2jmtiUZ0P9xvApnY56HwqSHjfR2kcrXLneid9Hzvlz7WXnIxQZPOVE0zW1tNU 9yBfvwO2ZletpmVltd/QrZQYxQL45nqDXe7G/JECHnRYBB89VKxpRFDJro0cU+6Pzh9U+H egxjYZHyT4BIlxQJRTywJaKT30hzpG6c7ABjqYjPl7pa2KU/N6PfIFSVu70t1TADpvMKwr JL3OzqstSQLpfjPRpt2N8sgG2iRn9lARLbIcjNLfWs7LjqIa6fsB9fhnMq9r4A== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgQRp-0001oP-50; Wed, 13 Sep 2023 10:02:33 -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 1qgQRT-0001ar-O8 for guix-devel@gnu.org; Wed, 13 Sep 2023 10:02:08 -0400 Received: from mail.webarch.email ([81.95.52.48]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgQRQ-0001ku-6T for guix-devel@gnu.org; Wed, 13 Sep 2023 10:02:07 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 0B9761A89C37; Wed, 13 Sep 2023 15:01:53 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msavoritias.me; s=20210930; t=1694613719; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=5yaF00NPS9X0TqFqiBcmLb3WOl8+pxEp6IZeB35+Phw=; b=P0GA/F/GqsXMSuA9EYqp9A+g+bK9GwdUlI+3V/hMbkkuRfrBJt/yR5bsD9WLF7eTXn7lud OD16lF+r16SiTU6oWT54DSYS2k/N8aR1kavi5Gj5B4YmjDuUSgd5lPjdh9nIaUOgZbLTOE K/nZdNZ+wvNUGUunO9zaPvpRjne9As1xfdSMw+m0OE7+qvUUqvYIGD5jaGidnaZsay5+p0 Vom0DFxRDGOPjfMaJ6KJ7ihxN19rEM0FpJQ8hMzevogosFL2HG03VrHLd9z6vqUnfrUIFD pbK8AEldlsP07FI0JKdPsmp1b3jW4AfBM3SGlKu8ievGkcJe9zYHmyhT3IlTFg== References: <871qfsuvad.fsf@gmail.com> <8e74c4ac-a6f3-9127-7e13-593a2eb70432@gmail.com> <87a5ubqxm6.fsf@gmail.com> <861qfcvhw2.fsf@gmail.com> User-agent: mu4e 1.10.5; emacs 28.2 From: MSavoritias To: Simon Tournier Cc: Katherine Cox-Buday , Vagrant Cascadian , guix-devel@gnu.org Subject: Re: How can we decrease the cognitive overhead for contributors? Date: Wed, 13 Sep 2023 16:59:16 +0300 In-reply-to: <861qfcvhw2.fsf@gmail.com> Message-ID: <87jzsurx2q.fsf@fannys.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Received-SPF: pass client-ip=81.95.52.48; envelope-from=email@msavoritias.me; helo=mail.webarch.email X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: 1.19 X-Spam-Score: 1.19 X-Migadu-Queue-Id: 8C1973C071 X-TUID: ybhiZ+0bi6Oq Simon Tournier writes: > 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 = and 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 b= ug. :-) > > >> =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 gett= ing inspiration. > > Well, as a rule of thumb, I am doing something like: > > 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. > > > In case of doubt, I am just running =E2=80=9Cgit log --grep=3D=E2=80=9D l= ooking 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 hav= e 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 idempot= ency. >> =C2=A0 16. Run `make` to ensure you didn't break anything elsewhere in = Guix. >> =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 differ= ent 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 = runs >> (sometimes a container is used for this. I think Guix has better options= !). >> Sometimes this is not feasible due to asymmetric resources. But having t= he >> 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= omission 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 g= et=20 >> the CC flags for Git >> =C2=A0 22. Remember that if you're sending multiple patches, an email f= irst=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 poin= t #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 specia= l=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, > > $ 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. > > > And because there is some variation with the commit message format, > these are not all the updates of VLC, > > $ 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]. > > 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. > Bear in mind that Sourcehut accepts patches without an account and there is forgefed https://forgefed.org/ for forges federation. which forgejo has support https://forgejo.org/ MSavoritias >> 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