From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id KCljGU7fzWXBKAAAe85BDQ:P1 (envelope-from ) for ; Thu, 15 Feb 2024 10:54:22 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id KCljGU7fzWXBKAAAe85BDQ (envelope-from ) for ; Thu, 15 Feb 2024 10:54:22 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TPq6xOWW; 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=1707990862; 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=ABkcuTGqTAAMfZ6wm61AMkloGB3kE3LjlT4oiAeWtTU=; b=CDMDOSY2Ufz6PxJn3gGBIgI3sVpIMYyMMkNDZqzxephLPgXAfZ+ePC2FnNnd52Yg+bC9Xh Rc7BUkSEJW5fRk8RKj41iRv8eI1+RUOBivLlTnq8OIbRJZgbOwvntrogAIXUP5j9DWJXtr fuyckUpC0jSk7D1hMuMDCz7qYofK95AXVxNJmJefoSgrKp6ealdlY/KI57K/PoSXSk4Lfl 1uicoHmS5kWvPUff05jT8UJWi8HvxMgqhdsHdAB9eMMwzsO4spG6UA0mhMbBfOX+9kozYb 5pbY7+xGR+kEaWbWQ1pP47T3QoVkXEhiT7ckGD2qkUdxQx9RcoXw3a/EIZZjeA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TPq6xOWW; 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-Seal: i=1; s=key1; d=yhetil.org; t=1707990862; a=rsa-sha256; cv=none; b=pRCcXDt5P+E1tEeLgHRDqtOPHNM9bXJ/eKWPy2U3NrMbiRZARwlRYRc445Tfk1NFtNRrKD YLgZwk2AANR/Dvc4b8SJg5dDDCYVOR0jG11bwaBw3zvQzXD6gBNmz8Ihm9wXSMm2IfLZ0j Inp9vNoervIBG2PqNVfUsIOmvzsvaohLsT8Szn0JxzcYFMJck2biDb4m7etgw/i465DNe0 idStQrkU0flOQas7IfmnOPWCQkAgcvmvjcvWQcrgGJoWb7/UmcCkk6E2PtzIXhHbnsPT3N mcnqITiwKrDMZ98WW91vHCVG84LUaGeFtpN8B+kZEKVK+JyEuihdYuw1qeneWw== 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 3484D23517 for ; Thu, 15 Feb 2024 10:54:22 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1raYQy-0000lC-RT; Thu, 15 Feb 2024 04:53:37 -0500 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 1raYQw-0000gs-L5; Thu, 15 Feb 2024 04:53:34 -0500 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1raYQu-0001EW-JC; Thu, 15 Feb 2024 04:53:34 -0500 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-410826218a7so1828585e9.1; Thu, 15 Feb 2024 01:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707990810; x=1708595610; 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=ABkcuTGqTAAMfZ6wm61AMkloGB3kE3LjlT4oiAeWtTU=; b=TPq6xOWW7i8afwSSWNYCYQxyKSzZ3nuX6b/rO8hJxHknBkcYKicvaAyiNGkPoPPjHb x73oFwdSxmuAIMv0tCwcSPTShsedvWkczIGkTZi92eyDeMf1r763fmF6w6ZHeysMB9X6 A2sd8vyD1Xf4pjP43VxyBTIM9FSdWUiKDYWF8rDZ5zVL8MfILN5x6ok6NQ0rruOHctSc YZg5vXP4L+RL2MDe+geZWG/MgT1v5xxvcoeth4STS3oeYzoJ37z858LB/KJad7i6Vw5x j94aAojZkN2CepuGRsJiY67psh4ZmNp+JxEBMUcOh584i95OGPgJEUiFXwETP0BPy7bP veLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707990810; x=1708595610; 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=ABkcuTGqTAAMfZ6wm61AMkloGB3kE3LjlT4oiAeWtTU=; b=XfWHHnVcLlLZufXHFXDzCPrgr6qX9chW/H4zMLWbF1yqb9TQ3hE6UUN/m5e9veMLu0 yqwON9JB8FqlTaDR/vmmGYDxwYOrn1baFjcrwDeMOxlvBOnLOIWsNoNHWzcOv3SI9Gw8 vK0yZS0F77d/lIipuh5idTR5+JoobbfXhndndqmUB9aLtMgDPSGyl+uWg0vhu9j13tcu NDIssQf3r24HR6xYKgZ7wkrFX2cDUKp8xJuEKeebG7RXZMP2HsGxSP6e9dcvp4IUye8G qiDvZYiPoDspvYMl0vT7kZ0YsLtiZpqYD55DuT7/bsXJiRqywKEtIFAX84d5U6thNaHx rYgQ== X-Forwarded-Encrypted: i=1; AJvYcCXB7SyNB5yR7KSRCIZZJIdmS+k/0txfSFjdFvUCS7kOIjdAhvImlau5Gw7/xR7nrRA+vhzYbQjZouDDdfTzfC4wf2k= X-Gm-Message-State: AOJu0Yzi91uwI45+eaCiMl5xpPE0k7PoJvNhIc6gTIT/igcjVbA9LSqD GxcJdKMtL40lfYp6n0B9a1sopPh3pLbEgMq9hEdfZKyfiebENVO17XUuYIAm X-Google-Smtp-Source: AGHT+IFZnTWlvuyNnZ08f49DgQWLS9bGhC0LuSthcomoScIVVslGUfqTfq3+fZrsC2b9p5iWwdKkQQ== X-Received: by 2002:a05:6000:382:b0:33b:7558:a834 with SMTP id u2-20020a056000038200b0033b7558a834mr1079140wrf.3.1707990809741; Thu, 15 Feb 2024 01:53:29 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:7d85:9c0b:111:5112]) by smtp.gmail.com with ESMTPSA id w11-20020adfec4b000000b0033b7ce8b496sm1222923wrn.108.2024.02.15.01.53.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 01:53:29 -0800 (PST) From: Simon Tournier To: Steve George , guix-devel@gnu.org Cc: help-guix@gnu.org Subject: Re: Guix Days: Patch flow discussion In-Reply-To: <10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net> References: <10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net> Date: Wed, 14 Feb 2024 22:40:40 +0100 Message-ID: <87ttmaiv1j.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::331; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x331.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, 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, T_SCC_BODY_TEXT_LINE=-0.01 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.78 X-Spam-Score: -9.78 X-Migadu-Queue-Id: 3484D23517 X-TUID: S8lu7N253nTi Hi Steve, ( On a side note, the triage of old bugs is a similar problem. They are easy to find [2], read, check and send an email to 12345@debbugs.gnu.org does not appear to me an issue with any tool. =20=20=20=20 For what it is worth and without any willing of being harsh, I am able to count the people doing this boring task. What is hard to solve is the incentives for doing the boring, but necessary, collective tasks. Bah the usual problem of lengthy discussions with roommates in any shared apartment: who clean the bathroom? :-) ) On lun., 05 f=C3=A9vr. 2024 at 09:39, Steve George wro= te: > Our goal for the discussion: > > How do we double the number of patches that are *reviewed* and > *applied* to Guix in the next six months? Thanks for these notes and leading the session. On my side, it was a fruitful discussion. Well, let me try to quickly summarize my conclusion of the session: 1. We have a social/organisational problem. 2. We have some tooling annoyances. The easy first: #2 about tools. The email workflow is often cited as part of the issue. That=E2=80=99s a false-problem, IMHO. Projects that use PR/MR workflow have the same problem. For instance, Julia [1] has 896 open PR. On my browser, it means 36 pages so if I go to =E2=80=93 25 PRs per page =E2=80=93 the still open submitted PRs: + the 6th page: around Sept.2023 and Oct. 2023 + the 12th page: around Apr. 2023 and Mar. 2023 + the 18th page: around Jul. 2022 and Mar. 2022 + the 24th page: around Jun. 2021 and May 2021 + the 30th page: around Mar. 2020 and Oct. 2019 + the 36th page: around Mar. 2017 and May. 2014 Obviously, an example is not a proof or an evidence. It is just a first clue. :-) I will not speak about the channel =E2=80=99nonguix=E2=80=99 but it gives a= nother clue. That said, for sure, the tools need more love. Thanks all the people for all hard work over the years in this area =E2=80=93 no name, you know, I fear to forget someone. ;-) So, yeah we need to smooth the technical burden for reviewing in order to focus on the review itself. To be clear, the email workflow might add burden on submitter side but I am doubtful it is really part of the bottleneck for reviewing and pushing submissions. Although the tools might add some unnecessary friction, the net of the issue is IMHO #1: reviewing is just boring and time-consuming. Who feel accountable? And for what? That=E2=80=99s the question, IMHO. If the number of submission is doubled, how do we increase the number of people that feel enough accountable for doing the boring work? ( Maybe accountable is not the correct word. Obligation neither. Well the kind of feeling that is okish if you skip the task but you know it will be better if you do it. ) Well, the difficult part is not pressing some buttons for merging and pushing =E2=80=93 whatever the tools or workflow. The difficult part is to scrutinize the submission. I think the bottleneck is not the number of people able to push. Instead, I think the bottleneck is the number of people confident with the change for then pushing it. The question is thus: how to build this confidence? Look, when a committer has some free-time, most of the time, what is the process: take first the =E2=80=9Ceasy=E2=80=9C submissions for committing t= hem =E2=80=93 from trivial updates to simple updates. If free-time remains, then engage with more =E2=80=9Ccomplex=E2=80=9D submissions=E2=80=A6 ah no more free-ti= me. :-) Why starting by the =E2=80=9Ceasy=E2=80=9D submission? Because it is less = boring and time-consuming; somehow it is easier to feel confident with that sort of change for pushing it. As a rule of thumb, about the time it takes =E2=80=93 on average =E2=80=93,= the order of magnitude for reviewing is similar as the one for submitting. Well, from my experience and although I never did stats. :-) All in all, I see two paths to move forward: i) Non-committers can help. On two fronts: + Answer to submitter with the changes for being compliant with Guix standards. =20=20=20 + Follow-up on patches already commented but without an updated revision: upgrade the re-roll count by sending this revision. It eases for merging if I do not have to make many tiny edits myself. ii) Create more teams or at least more people should commit to be part of a team and help in reviewing what they know. For instance, since Sept. (167 days ago) I have been CC in 108 patches submissions. Most of them are from =E2=80=99core=E2=80=99 team= that I would qualify as =E2=80=9Ccomplex=E2=80=9D. :-) Many patches assigned to =E2=80=99core=E2=80=99 team are sent by commit= ters. The issue is not being a committer or not. Instead, being more eyes commenting would increase the confidence. Thus it would reduce the workload. That=E2=80=99s the same for any team, IMHO. =20=20=20=20 And I do not speak about patches that are not assigned to any team. Somehow, we need to think how people would feel =E2=80=9Caccountable=E2=80= =9D for doing the collective tasks with low, no direct or personal reward. As with many non-technical topics, it is not easy. Because it is a collective journey not clearly identified =E2=80=93 and not a kind of reproducible bug to fix, even the tougher. Last, the manual says: =C2=AB As a rule of thumb, a contributor should have accumulated fifty (50) reviewed commits to be considered as a committer and have sustained their activity in the project for at least 6 months. =C2=BB So if people are willing to take more responsibility to help the project=E2=80=A6 Well, while writing that I could have give a look to patches=E2=80=A6 ;-) Cheers, simon 1: https://github.com/JuliaLang/julia 2: https://issues.guix.gnu.org/forgotten