From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 qFzMLkOD62RjfQAAG6o9tA:P1 (envelope-from ) for ; Sun, 27 Aug 2023 19:09:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id qFzMLkOD62RjfQAAG6o9tA (envelope-from ) for ; Sun, 27 Aug 2023 19:09:23 +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 47FE5515CA for ; Sun, 27 Aug 2023 19:09:23 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ETkTfVJb; 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=1693156163; 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=pSMb4c7Vi5Z8zPnwRHQRkaLRmOg9T/YIEYUuCiYVvyw=; b=ddUfxKIfvL6vG/zh4GbfgPZsFP7U7iIY3EaTz96cCR5rMA9Fdca0mnctNoHMHMJ8vG/YD6 XtDdEf1xMZ0ejA9Is8547hh1oMV8Sc52Jk5ZFFFJO4jLDjY9SW3uG00WQ1QoVK01DU4FTr kml7Wu//kF00/fkTCgzywSWstpcA2s49Ek5KdCTVeQQi53GzX9+7Nkj+KGfZmMj0gz/Dng CeC+KbmDaP025sWfTEMMUFWbcRGi2tEHhtF6nqXxYJdoCmdRdOGD/GQc6GmnT7V7LloTBe 4Re5vAFr4thvdigtEVgurSzAan/x5tffm5c1+0U8cPR+IFuiWr23+9KCClbfFw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ETkTfVJb; 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=1693156163; a=rsa-sha256; cv=none; b=Xyo2EcMmuCmnUULYkwj4gIspHwaC4pqXT3odTP+gqxtEd57vveEJV+9u6wys9FBwI0KJKY 3cqlEoys5pOcxJWrEHWCOyj7kAKEGls8nanV6dsolHt4fGhb/EYBUv+EH4hmAWxgIQs76F L4iQgWhQNq9NsuoHFUykhKVJaFjc7CnMFtC8tOvv2VLBeL5Ar/ZxTRv3qaYfMfKU/9qQMo q4lJ5VUwFROcDFqdT/K0r0GuN+RVnknyYMVYjiTu4U+hc7cP/6HEY2+vdEouxqLjHUi724 55+dh6WSPGRPJoFoyzw2oDtpQeY0z2H2sucljwp+bljofXidbklc4BQ1qCqB5A== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaJFm-00046s-DY; Sun, 27 Aug 2023 13:08:46 -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 1qaJFl-00046W-Ir for guix-devel@gnu.org; Sun, 27 Aug 2023 13:08:45 -0400 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qaJFj-0008U3-3l for guix-devel@gnu.org; Sun, 27 Aug 2023 13:08:45 -0400 Received: by mail-lf1-x142.google.com with SMTP id 2adb3069b0e04-5008d16cc36so3750531e87.2 for ; Sun, 27 Aug 2023 10:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693156121; x=1693760921; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=pSMb4c7Vi5Z8zPnwRHQRkaLRmOg9T/YIEYUuCiYVvyw=; b=ETkTfVJb03un+CzZBtU5xQjLwx7E7rxBmerzyWX6Bb6dqowzzroi9+3ebHAdDF7grz 7SBTCYD4xcBJD/zJmZ7WazmUpGfN/UKldQRhaiv/QfufwE+F6m7FNHNG6vaCSKHconXD OrQiTzih6V9/Etp3EpP7Y23wgRqjAXKCEQWPXL6rFfcOLKxGEsrVYEKVfgfOP7uTwKQE dSCDavSFkNCFH43ui8dtvphyMsEaG9cqhA5lkLLKP0urbcuTmAYCrfCc40cImHNOJkB+ U7VpMGst4mCUUEbzuN5gHaZ9K9glvQlHF5w4H9MCtiEsJE/oQn/GgOkZSDCp274QErQG M/gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693156121; x=1693760921; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pSMb4c7Vi5Z8zPnwRHQRkaLRmOg9T/YIEYUuCiYVvyw=; b=METbPIUuM6CNXr3+zNyQ55wM0ciHAQHvPvQLlXR3dBEygq9dNkF82Dz8Wfctr9FGOh C/JBT3LFZAY3E7ZTcy4baJBYDI7V6Y9oxP+FgWja1FPJZsrfiX29VMoBr+KQLk8M9ooU +3bvm48K//cI0Z9CDD7I1PwYtX9WONU5e/o2O+lOTCndGTUMzz7524CcXiSPtYwRkBDM vsdBif9FIvMxeR30/yi6OTHfIbRtFqy3CEW0y6cbgxVXuwCROa2AXKPykdd+1gBzVCGn l/HXoNvtWEFI/Y152DPerp+Lzt/cmv8jc8RiKRXAo/Yz9028+LxbJMdpjJuXH10Aovh+ irDw== X-Gm-Message-State: AOJu0Yx3eoir27hYZt+IZ62mF2BevZCfe8chXNZediZ+GyXpA/QHfk2n Hbz5voUd0TNE47jQ9DYBq6hvP5WnUc+v7Wjd X-Google-Smtp-Source: AGHT+IGydOo/NPgWRdrqYARCVgMQW/edGh0LcAiLyTNrvRhDXqIOmVDiPAQXpYTSS7RjxflkmKbh8A== X-Received: by 2002:a05:6512:31c8:b0:4fb:9772:6639 with SMTP id j8-20020a05651231c800b004fb97726639mr18884413lfe.6.1693156120565; Sun, 27 Aug 2023 10:08:40 -0700 (PDT) Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id i9-20020aa7c709000000b0052a198d8a4dsm3515155edq.52.2023.08.27.10.08.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Aug 2023 10:08:39 -0700 (PDT) Message-ID: Subject: Re: How can we decrease the cognitive overhead for contributors? From: Liliana Marie Prikler To: Saku Laesvuori , Attila Lendvai Cc: Andreas Enge , "Felix \"Lechner via Development of GNU Guix and the GNU ""Systemtdistribution.\"" , Katherine Cox-Buday Date: Sun, 27 Aug 2023 19:08:38 +0200 In-Reply-To: <20230827135726.y33t55w4cvq6zsvb@X-kone> References: <20230827135726.y33t55w4cvq6zsvb@X-kone> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 Received-SPF: pass client-ip=2a00:1450:4864:20::142; envelope-from=liliana.prikler@gmail.com; helo=mail-lf1-x142.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-Migadu-Spam-Score: -7.08 X-Spam-Score: -7.08 X-Migadu-Queue-Id: 47FE5515CA X-TUID: HtANAIPx1b3V Hi, Am Sonntag, dem 27.08.2023 um 16:57 +0300 schrieb Saku Laesvuori: > > >=20 > > not sure how most people consume their emails nowadays, but for me > > it's one flat list per thread, in a browser (i.e. it's not a tree). >=20 > The point is that the emails contain the information on how to > construct a tree out of them. It's just that most web clients (which > most people are unfortunately using nowadays) are so bad that they > render the tree as a flat list. Not sure about "most", but Guix folk are definitely biased towards dedicated mail clients (terminal, graphical, Emacs=E2=80=A6), so perhaps my= own perception was a little off in that people will always benefit from having the tree. Then again, you can share your email between multiple clients, which isn't that easy to do with code repositories sadly. =C2=A0 Of course, you can mirror the repo, but your bug trackers aren't that easily mirrored. >=20 > > and all i'm trying to achieve here is to move the discussion away > > from email-is-superior-period, to look at what requiremenets we > > have and what tools satisfy them, if any. >=20 > I think that is a good discussion to have, but I think it would be > better to describe some of the requirements you think we should > consider instead of just saying email isn't superior. It might not > be, but it might also be. We should consider what we need and > evaluate the available tools based on that, and if the result is that > email is the best then it is. Not needing to register yet another account for one-off contributions is an argument that kills all the forges, sadly :) > > > at the ChatGPT-related stuff that has been submitted). There > > > sadly is no pleasing everyone here and unless these tools are > > > incredibly simple to maintain, the utilitarian approach of least > > > misery leads you to plain email. > >=20 > > but is a least-misery model appropriate here? how do you even > > account for the contributions that could have happened in a > > different environment, but did not happen? > >=20 > > similarly, e.g. demanding a dated ChangeLog format for commit > > messages has a filtering effect on who will contribute, and then > > who will stick around. most engineers have a hard time jumping > > through hoops that they find pointless (git automatically encodes > > that information), and i'd suggest considering what the effect are > > of such rules on Guix asan emergent order. >=20 > I agree on the ChangeLogs being a weird thing to require in commit > messages. I think of commit messages as the place where you record > the reasons behind the change in the commit. The ChangeLog seems to > just record the changes which the diff of the commit already > automatically records more accurately. First things first, I disagree with the framing here. Engineers do pointless things all the time and both code style and commit message style have near endless potential for bikeshedding (which we are currently engaged in btw). There are like thirteen competing standards on how to format C code and similar debates in other languages. In fact, I'd go so far as to argue that a language ecosystem that has no such debate is potentially lacking in diversity. A proper ChangeLog doesn't simply "record the changes the diff already records more accurately". It adds semantics. For instance, when bumping a package, we write the same line twice; once for the header, once for the ChangeLog. What we don't write is that we also adjusted the hash along with the version. Doing so would give us no new information, but the diff includes it anyway, because diffs are stupid. Humans writing (and reading) ChangeLogs aren't stupid and can rely on contextual meta-information =E2=80=93 however, the ChangeLog should still b= e self-contained in the sense that it doesn't rely on other parts of the message to infer the actual changes made. > If someone has use cases for the ChangeLog commits, I'd like to hear > them. Maybe there is something that can't be achieved with git > history without ChangeLogs, but I can't think of anything. Someone > mentioned grepping the git log with them, but I think the same thing > can be done with git log and git blame regardless of the commit > message format. In my humble opinion, you underestimate the benefits of not having to invoke another command on a commit. For a great number of changes, the ChangeLog style allows me to imagine the code that was written without having to see it in a way that a simple diffstat just can't. Of course, whether you use ChangeLog style commit messages, Emoji commits or any other formatting guide is a political question between everyone involved in a project, but there are benefits to having guidelines and following them. =C2=A0 It's similar to following generally accepted etiquette in any circle.=20 People will generally be happy as long as you follow them and can often tolerate small deviations, but at a certain point it just becomes uncomfortable, so we kindly ask you to follow the established practices. Cheers