From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id MN0dG35+92QgMwAA9RJhRA:P1 (envelope-from ) for ; Tue, 05 Sep 2023 21:16:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id MN0dG35+92QgMwAA9RJhRA (envelope-from ) for ; Tue, 05 Sep 2023 21:16:14 +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 EAE0E33C8F for ; Tue, 5 Sep 2023 21:16:13 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=LjciFDCj; 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=1693941374; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=stqwshyjyPz1XNuntJXfjS32hu5nCpNXfS/Oqx6UdXU=; b=XcTYnnWP6918ee1y8qkloFdn1l82v83136ltn9YY0IIrCWkJyDITik4lrZQK7ja9Tdb8Hn xTtIZMj/jUmVzSDAVavlIp09C+TtuXwSE/6V7oZT/QqBoe2QfKMEQl6VxkJykMYxCMlswh f6Wq8b4KydCESPtGeTocSG0Uzij4qwIMauJqBtU3XSrRKvl+LjgQK60dRdS9aT/U4bZPIh kmsjEAA83GSd49FEdcQCpEYa2Z7IdvTd31jK6WUB0T173NGwtMv8fDolkSpFWW4XzNxSJ0 oBOaksDFyGQA9TO0nhO4GzbPTZPOhQHDkLZ9HhCpXOQ7nUu9LmNtWPHMtHGufw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693941374; a=rsa-sha256; cv=none; b=Bn+lb+8p6EtGsJqrJjqCXvF/jp4iB8GPi27zTXLH9w6oPHS7Ojh9057YWFl2tdtsujvFui ev8sjKLmRwBtcUDJHetcQWFgQHaQsAYdQIBLZoctWAgZfs5KdwHokk2OH4d/Dfha+6rpPg LgGbKhyQh67+SHIPa1MbWGWSE9GM07iiO61IPpP2Ee6Iyd65I0IdADLpbDQ6jQzzOxoRD5 sy7rsM8tJMOLoIi5GTwxmapB1ijMDaNAk+qwhDxWOKzVBwl2J5zEkA1rGlAss5BDAJHpRl RsJkDujJiED6vXF2fs3PIyMLfUoxbRiJtEKm/nuuBEGXekAE5TATPDwuLV+x8g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=LjciFDCj; 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 1qdbWm-0002vi-05; Tue, 05 Sep 2023 15:15:56 -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 1qdbWl-0002vK-34 for guix-devel@gnu.org; Tue, 05 Sep 2023 15:15:55 -0400 Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qdbWh-0000B5-RK for guix-devel@gnu.org; Tue, 05 Sep 2023 15:15:54 -0400 Received: by mail-io1-xd30.google.com with SMTP id ca18e2360f4ac-792623074edso4852339f.1 for ; Tue, 05 Sep 2023 12:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693941350; x=1694546150; darn=gnu.org; h=content-transfer-encoding:in-reply-to:from:references:newsgroups:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=stqwshyjyPz1XNuntJXfjS32hu5nCpNXfS/Oqx6UdXU=; b=LjciFDCjVDv9WHkkClbxHRW9GFuJpL/71oFRt+1LFelM8hUIXyEUUIbfPzHLoCSyug NCkcviulMMMnsniJ6GZvmYnoXlzQBXazcrD4dsQLIXHlnMd5BMtmVThXI4ZFh7/bUlW1 nf7FGoRfntAVaWMpobGptrH2sLOzqFmBg9fGODcappqos2bHua3xjCiR/Bpou4Tz+n1f axuyt+sJJxBnm9e5aCrcbBe9kHP5hsq3dX7zB6XNof8ZgiP2dgcgSjyaWz01WEbvAuHa NLcbu6nbSZlV7xY09cMaUOonmAj4TYU9jdW3s5OORwMu069hwyeJ+2FmEWzna3z99Giw Rm6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693941350; x=1694546150; h=content-transfer-encoding:in-reply-to:from:references:newsgroups:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=stqwshyjyPz1XNuntJXfjS32hu5nCpNXfS/Oqx6UdXU=; b=EIgfQ+lv1UkRlLvgcLD7pWukvRsZZx6vSA0cvM0JRpsIJuGhygqn0cUwLAwBkYwu+3 0XlkkQnCZEP0EvD7FVB0H4Zy/kpbpswICiIOWEcNDpwWqCgOXiQy9bfCk1I8p0uEwB8n VgZ2xwhSC06aYKn0JXZU9NhEWW7pfgI1ZpE2nBxEhxdwHjttsK1jBEkyAxtHzQAAPB+H mSxMW5pr75UJcA+H17mo3wntyz0bqySy+eKKo8XAppr1GnN20NaAXEVMKhupImAqUKXQ t0c3TWyQw2NFV99Uw/Ve6jyOy9ec1qu89gcf1589dp5l4nOJRrRhpWzMmoRQkwmhIjhc qoEA== X-Gm-Message-State: AOJu0Yz4YQ9Ds1+NtvecSYSfF7abepDdF3lK8v4/k9K/caQF/DRSvxPf g77mWHV3pQUcZgANmcC8CggLACooUes= X-Google-Smtp-Source: AGHT+IGapwnMNaJvh4nBsyXsfYQc15Kj4F9eo6kKKO4txBr0Me64Z27S9LRmY4fC0jH8CREOCjDEsQ== X-Received: by 2002:a05:6e02:ca3:b0:34c:e630:e99 with SMTP id 3-20020a056e020ca300b0034ce6300e99mr13424755ilg.11.1693941350072; Tue, 05 Sep 2023 12:15:50 -0700 (PDT) Received: from [10.0.2.153] (c-174-51-218-141.hsd1.co.comcast.net. [174.51.218.141]) by smtp.gmail.com with ESMTPSA id x10-20020a92d30a000000b003423af2fda6sm4366203ila.83.2023.09.05.12.15.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 12:15:49 -0700 (PDT) Message-ID: <13416fee-8c7d-b145-48b9-0fbec22517b1@gmail.com> Date: Tue, 5 Sep 2023 13:15:48 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: How can we decrease the cognitive overhead for contributors? Content-Language: en-US To: Giovanni Biscuolo , guix-devel Newsgroups: gmane.comp.gnu.guix.devel References: <871qfsuvad.fsf@gmail.com> <8e74c4ac-a6f3-9127-7e13-593a2eb70432@gmail.com> <87a5ubqxm6.fsf@gmail.com> <877cp8965f.fsf@xelera.eu> From: Katherine Cox-Buday In-Reply-To: <877cp8965f.fsf@xelera.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::d30; envelope-from=cox.katherine.e@gmail.com; helo=mail-io1-xd30.google.com X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 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, NICE_REPLY_A=-1.473, 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: mx0.migadu.com X-Migadu-Spam-Score: -5.59 X-Spam-Score: -5.59 X-Migadu-Queue-Id: EAE0E33C8F X-TUID: 5NH1ouqoZRA5 Thank you for your thoughtful comments, Giovanni! On 9/2/23 5:16 AM, Giovanni Biscuolo wrote: >> 1. We should use sourcehut or continue to improve mumi > > Please forgive me if I insist, but the one and _only_ benefit of using > SourceHut is the web-UI /helper/ to prepare an email message to send, > it's "just" a web-UI version of the "git format-patch" CLI; the rest of > the "patch management workflow" is email **and** CLI (git am) based; > it's documented. I enumerated the underlying issues that both my suggestions would address: - QA status should be visible from a patch's page - It should be possible to interact with the issue through the page I know everyone is focusing on email vs. web-forge, but I am trying to draw attention to the root causes of the complexity, and enumerating possible solutions to these. Please notice that under my first suggestion, I was calling out points about how QA status shows up, and switching between tools to interact with issues, not specifically how to prepare/apply patches. > Furthermore, users that are comfortable with the SourceHut web UI are > free to use that as their personal working repo, there is no need for > Guix to use a SourceHut remote as the official one. Defaults matter, and I don't view it as a valid starting-point to state that contributors can manage intrinsic complexity on their own. I think that's where we're at right now, and it's why I created this thread. >>    - QA status should be visable from a patch's page > > On mumi web interface, in each issue page related to a patch, there is a > "badge" linking to the QA status for that patch, right below the issue > title; i.e.: > > https://issues.guix.gnu.org/65694 > > have a link to https://qa.guix.gnu.org/issue/65694 > > QA (and relates services, like data.qa) is a great project that could > greatly improve current situation when completed! Agreed! I called out Mumi as helpful but also highlighted some areas for improvement: In a web-forge, I generally have a URL I can go to and see everything about my patch. I think we have that with https://issues.guix.gnu.org with two exceptions: (1) QA is a click away, or if you're using email, you're not even aware that there's a QA process failing (2) If you're not using email, context-switching between this page and email to respond. >> - It should be possible to interact with the issue through the page > > I don't exactly understand: what do you mean with "interact"? It should be possible to perform almost all meta-activities against an issue through its page: - Manage status (close, re-open) - Manage tags - Request reviewers - See CI status including high-level reason(s) for failure - Apply to parent branch - Respond to comments > ...and what page? https://issues.guix.gnu.org/ or > https://qa.guix.gnu.org/issue/65694 (or any other issue) Right now I'd hold up https://issues.guix.gnu.org/ as our best example. >> 2. We should create scripts/sub-commands to lift contribution activities >> into >>    higher-order concepts: >>    - Prepare a new submission >>    - Run pre-checks on a submission >>    - Submit a patch >>    - Status of patch > > AFAIU you already use some of this "lifting" scripts od commands: can > you please send patches so thay could possibly be included in Guix > proper or in some section of the Cookbook? It's not a stand-alone script that I can share unfortunately. It's functions integrated into a more complicated system. However, it's pretty straightforward to recreate: anywhere there's a decision-point, infer the correct decision (e.g. check dependencies on a package to determine which branch a commit should go in), execute the list of steps, give a human-friendly description of anything that went wrong, and offer suggestions on how to correct it. >> For me, steps 20-23 are bothersome. There's a lot of "if" statements >> that lead >> to branching operations, and a lot of commands and flags to get >> right. > > oh yes, CLI is a cognitive overhead sometimes, so we need better > interfaces, some have found them I loathe working with workflows that don't have integration points, and so I *love* CLI tools. But I don't like having to be the computer and walking through a workflow while filling all the blanks in. > actually, point 21 "Run `./pre-inst-env ./etc/teams.scm cc-members > ` to get the CC flags for Git" is bothersome and we should find a > way to better integrate that in "git format-patch" (so that will be > automatically used in all the git interfaces we use) > >> The extra step to get a debbugs ID is annoying. > > have you tried mumi CLI with the new feature? No, I've never used the mumi CLI. > Forgive me if I insist: that forge site is _not_ SourceHut > > Second: each forge web site have a custom (not standard) way to manage > pull-requests. OK. I am not particularly attached to any one tool. I only care about reducing the complexity. I was responding to a message requesting specific suggestions, and Sourcehut has been brought up. > Third: git have a pull-request mechanism [1] that could _easily_ be > integrated in each and every forge, allowing projects to use > /interoperable/ email based pull-request workflows if they want to. Great! Let's talk about all the solutions so we find one that meets our defined criteria. > IMO the > core and most cognitive challenging steps of all "CI steps" are not if > builds are done locally or not but (in order of importance): > > 1. having patches reviewed by humans, the "not automatable" part because > Someone™ have to understand the _meaning_ of the patch and verify it > conforms to the coding standards of the project, including "changelog > style" commit messages; I think the complexity required to contribute and having patches reviewed by humans are causally and cyclically linked. I would like to contribute much more to Guix, and others have said the same in this thread. Some of these issues we're discussing are preventing people from doing so. I.e., would you rather have: 1. 10 very efficient contributors 2. 1,000 moderately efficient contributors Wouldn't it be great if we had both? > 2. understanding why build derivation fail when it fails. > > This is real cognitive overhead and this cannot be automated. I disagree with this, but that's another conversation. >> - Steps 19-23, or the "manage patch" steps. >> >>   I think an insight here is that the big button on forges is actually >> a program >>   removing the mental overhead for you. > > On the "web forges" vs "email based" patch workflow management I've said > enough in other messages in this thread, here I just want to add > (repeat) this: please do not only consider the mental overhead of > potential contributors for "managing patches", also consider the mental > overhead for patch reviewers; I've read many articles from professional > patch reviewers that perfectly explains the great advanteges of using an > email based workflow It's a good point. We should remain focused on the overall complexity of the complete workflow of getting working code into Guix. >>   I also don't usually have to worry nearly as much about crafting a commit >>   message. So long as the title is under a character limit, and the body is >>   helpful, it's OK. I think what bothers me most about the GNU changelog >>   messages is that it's the worst of both spoken language and programming >>   languages: there's an expectation of structure, but no grammar I can >> parse >>   against, and it's free-form. > > I'm sorry that the GNU policy about commit messages bothers you (on the > contrary it makes me happy); please consider that thai is /just/ one of > the policies of the Guix project: code of conduct, coding standards, > others? I recently responded to a similar question/point in another message from Simon about this being similar to style standard: The distinction I draw is that I can usually run a linter against a coding style. I don't care very much what the standard for commit messages is other than if it has an expectation of structure, I be able to run a tool to tell me if it's wrong. In other words, the overhead isn't "I don't like this standard", it's "I can't find a way to reliably adhere to the standard". > it's "just" an _interface_ issue I think I would agree with this! I don't know that there's an inherent complexity in the individual steps. It's the aggregate of managing the workflow and tools that I think makes things complicated.