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 KOhZBN+y92S5hwAAG6o9tA:P1 (envelope-from ) for ; Wed, 06 Sep 2023 00:59:43 +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 KOhZBN+y92S5hwAAG6o9tA (envelope-from ) for ; Wed, 06 Sep 2023 00:59:43 +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 B661353F1F for ; Wed, 6 Sep 2023 00:59:42 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=T8r93Svd; 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=1693954783; 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=a9ktkftN2V0FBa4K3QV0xmX7wv3+v+SMYijARlNL3EE=; b=UhSMqUY2IytjZ3Hoyx/sL+acPDsoNUnimJ3vELtERGHyvN8X0yC/nn181w/7Sq8IOB30CE i4mlvnjlI9jRLZXnkmskPDHirS/zcclLKufCAMc0+VsL1pbdcHpjhS5/Q71Qa1X6lWQHzB hWEaFq0CoKkcFHsP4LlHnrumqFRBUM5Rj5lu0DDj9vHj2UEPpbzEs2/kw49glWX2j4fe6R nnk937R9LVePGLyAW1C7XsDLqf2ySzCiXF+OpKcxhphaiUCuzq8v0C+szMSeM75oxv80Dl Ck1sdaRlngnkD+j6n6efUAYVWNC0Ka///Hand1tL0i8kUSJ2LucYKWkWmj53bw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693954783; a=rsa-sha256; cv=none; b=f+t1fbFKGKthkZZgB5muCpgo3txA7LV8fThcMNOXBF3hLiO9ZM31+rK5uxvOAmnr7x/gAL EnCHBhbGGjgNClMR9DuIOMJdsYTQQbwqEk+COfuh+qtH+/UhjZ8gKTdgFJLC72OH1BZErc ofltiY0t+MDtV4yJqWv19GnN8fHf+nrvZMUN9EkflUV6UNwIr25dvZTQSyOjc7nRIKGMW8 LWAKJqbiG2IvQvhMyZrzEf0fIUyZthwD/Ko8JnhQdhHWrdKyEufhqCz+JAbwlHY/nXBRHa wiiV+ylWO8D4vGLzAt463AvdLZjEPE1Ib/rRoB8V+Co1dzA1GtDGhzoWiuelBQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=T8r93Svd; 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 1qdf0o-0005dR-5O; Tue, 05 Sep 2023 18:59:10 -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 1qdf0m-0005d3-2z for guix-devel@gnu.org; Tue, 05 Sep 2023 18:59:08 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qdf0j-00028M-6R for guix-devel@gnu.org; Tue, 05 Sep 2023 18:59:07 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-3fe4f3b5f25so8744255e9.0 for ; Tue, 05 Sep 2023 15:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693954743; x=1694559543; 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=a9ktkftN2V0FBa4K3QV0xmX7wv3+v+SMYijARlNL3EE=; b=T8r93Svd71zKFvPiuys1RlBGuAGe8lLkNdJow74m5rXSHiWuIUmkqDums5Eu1KXeDe IxQs+oujl1mbGwiV/CuVibH6d66jIjhUTmQQjPm/8FamAcon2lP8q45kyQ+PDVYwF+ot S0At3F9kmu3MQ0/QbQnmgYid2W6ZYHwhbBWBujGDgyw0Efmz8ttftk72jUB7SrYwX9yP ru3TNu8HDBIMP70WU5aGydaql9exZkW63BlxLSIJ8Wv/uoqpMre5Y5AZhy7Ffei0KYK2 LM4xR/yaHoDSDKxuqtAgG8qro1iiBhoD8tePaiiv0Zfr5aBl/Jl6Cj/mFriuD6kcE24w MmyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693954743; x=1694559543; 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=a9ktkftN2V0FBa4K3QV0xmX7wv3+v+SMYijARlNL3EE=; b=f0wAwH++md5YYfQdLOCsh/LhKkYQ4oBhn4/hIk6OiRD+oQTTOoP72SYvt8n7MjTcPF GBK4Vl9l37nLZLAI2M98X1XsOd+0fOjrlxvX9MCDtmu1A70wYhoeLgrnTlORrFDG1vH2 0yMlpAD3yNM/4qr8h1UBO9Q1ORzDPKd2xGtIi18SHdUzP9Yf9fmq6oS2CXnIX19EGSne T8ABK9inBcYn9uScVHlWcn0JgoYrwFA1x07RjLbAnw0XsOT7S9g/eJDKOdywrtkQtTJR PB/7TXgeKnd242vBNa2InPzaJ33RNW05jp6ZCsJX6hgn9MRvElcV6WCWVq2FDpg8FmLV 0j8g== X-Gm-Message-State: AOJu0YywaZaxCGxKcgZeqmDh9x0wzzzWbAVYHtgbCiqbigTFc5N15axD F5HGH8ipnDl2UurLvpBXLgwcmeLJT9o= X-Google-Smtp-Source: AGHT+IFBZPZockArq7lnR5i3SJki2IIkhl1v0O68L8WhOzmnJ8H+V8ULLNSaUGBd/MjHXYUv2yjTpA== X-Received: by 2002:a05:600c:1c8f:b0:3fe:21a6:a18 with SMTP id k15-20020a05600c1c8f00b003fe21a60a18mr11362804wms.3.1693954743429; Tue, 05 Sep 2023 15:59:03 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id o24-20020a05600c379800b003fed70fb09dsm18183126wmr.26.2023.09.05.15.59.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Sep 2023 15:59:02 -0700 (PDT) From: Simon Tournier To: Katherine Cox-Buday , Maxim Cournoyer , Saku Laesvuori Cc: Attila Lendvai , Liliana Marie Prikler , Andreas Enge , "Felix Lechner via Development of GNU Guix and the GNU Systemtdistribution." Subject: Re: How can we decrease the cognitive overhead for contributors? In-Reply-To: <38242808-2f06-4674-3842-aea1a5378d05@gmail.com> References: <20230827135726.y33t55w4cvq6zsvb@X-kone> <874jkift8v.fsf@gmail.com> <867cp4sj7k.fsf@gmail.com> <38242808-2f06-4674-3842-aea1a5378d05@gmail.com> Date: Wed, 06 Sep 2023 00:57:17 +0200 Message-ID: <86v8cop6sy.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::32c; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x32c.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: -4.08 X-Migadu-Queue-Id: B661353F1F X-Migadu-Spam-Score: -4.08 X-TUID: iJyG8uuvpxkC Hi, On Tue, 05 Sep 2023 at 11:01, Katherine Cox-Buday wrote: >> Well, somehow, I consider the commit message format similarly as coding >> style. We can discuss which one is better than the other when at the >> end it only reflects some artificial preferences and for the sake of any >> project one needs to be arbitrarily picked. Why not ChangeLog? > > 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". Well, I am not sure to fully understand what you have in mind with the term =E2=80=9Cstandard=E2=80=9C. To me, coding style or similarly commit m= essage format are about standard or norm, meaning they respect a set of rules. The question is then: is it possible to explicitly write down all the rules? Are all the rules all well-defined or are some ambiguous? etc. For some norm or standard, it is possible to have a checker because all the rules are explicitly well-defined. For many norms/standards, we do not have any checker. The current norm/standard for replying to these Guix mailing lists is bottom-posting. We do not have a way to reliably adhere to this norm/standard and we are not commenting or discussing more about it. Because this norm is easy to internalize. Now, I have read the thread and I hear the comments about the commit message format as ChangeLog. To be honest, I am somehow surprised. If after being enough annoyed by something that then one clones the Guix repository, finds how to improve and last drops all because writing the commit message is too =E2=80=9Ccomplex=E2=80=9D or because one does not kno= w if the commit message correctly adhere to the standard=E2=80=A6 Sorry, I do not bu= y. And I do not buy either an issue when resuming after an interruption because writing commit message can be done from the diff. More than often, I tweak stuff, then commit with the oneline subject =E2=80=99DRAFT f= oo=E2=80=99, continue to tweak, commit =E2=80=99DRAFT bar=E2=80=99. Days or weeks (or m= onths) later, I resume my work and run =E2=80=9Cgit rebase=E2=80=9D for polishing the com= mit =E2=80=99DRAFT foo=E2=80=99 and preparing it for submission. Again I hear all the comments and I am trying hard to understand. From my point of view and from where I stand, my understanding is that the core point of commit message format is about 1. discipline =E2=80=93 the qu= ality of being able to behave and work in a controlled way which involves obeying particular rules or standards =E2=80=93 and 2. confidence =E2=80=93= the willing to send the perfect message on the first try. And there is no tool for fixing these both issues. Example of a imperfect message: a957171bc41e98e29674f99cf3dd2940ff45a0d3. Typo! :-) --8<---------------cut here---------------start------------->8--- Author: Simon Tournier gnu: ocaml-mdx: Fix tests. * gnu/packages/ocaml.scm (ocaml-mdx)[arguments]: Substitue obsolete 'egrep'= by 'grep -E'. Signed-off-by: Julien Lepiller --8<---------------cut here---------------end--------------->8--- Oops, that=E2=80=99s npt perfect although I did my best (proofread and spellchecker), the patch was in the tracker for some time and I am sure Julien carefully checked. Yeah, commit messages are boring to write. However, when investigating and trying to understand some changes, it appears to me far more useful this: --8<---------------cut here---------------start------------->8--- ec0a2fc87bd651ebc8f253f6369ba4485912d9b2 upstream: 'update-package-source' edits input fields. Previously, 'guix refresh r-ggplot2 -u' and similar commands would print of list of input changes that would have to be made manually. With this change, 'guix refresh -u' takes care of updating input fields automatically. * guix/upstream.scm (update-package-inputs): New procedure. (update-package-source): Call it when 'upstream-source-inputs' returns true. * guix/scripts/refresh.scm (update-package): Remove iteration over the result of 'changed-inputs'. * guix/import/test.scm (available-updates): Add support for input lists. * tests/guix-refresh.sh (GUIX_TEST_UPDATER_TARGETS): Add input list for "the-test-package". Make sure 'guix refresh -u' updates 'inputs' accordingly. * doc/guix.texi (Invoking guix refresh): Mention it. --8<---------------cut here---------------end--------------->8--- Where the diff looks like: 5 files changed, 72 insertions(+), 45 deletions(-) doc/guix.texi | 5 +++-- guix/import/test.scm | 13 ++++++++++- guix/scripts/refresh.scm | 36 ------------------------------- guix/upstream.scm | 56 +++++++++++++++++++++++++++++++++++++= +++++++---- tests/guix-refresh.sh | 7 ++++-- compared to top-notch project as Julia language: --8<---------------cut here---------------start------------->8--- sysimg: Allow loading a system image that is already present in memory (#51= 121) I've written this code probably three times at this point, but for some reason it never made it into a PR. This allows loading a system image that has already been loaded into memory. This happen when wanting to distribute a static or mostly-static binary of julia code where the system image (and optionally other libraries like libjulia, etc.) are linked directly into the main executable. It is also useful for deployment to environments that do not have (or have incomplete) support --8<---------------cut here---------------end--------------->8--- where the diff looks like: 6 files changed, 45 insertions(+), 10 deletions(-) src/Makefile | 2 +- src/init.c | 7 +++++-- src/julia.h | 2 +- src/julia_internal.h | 11 +++++++++++ src/processor.cpp | 10 +++++++++- src/staticdata.c | 23 ++++++++++++++++++----- Well, there is no comparison about the quality between the two commits, IMHO. On one hand, we have an clear idea about the change and what exactly had been modified. On the other hand, bah one needs to be comfortable with the code and directly jumps to the diff hunks. Which commit message is helping irregular contributor or newcomer? The one which requires to internalize some rules? Or the one easier to type? Well, I share various points that had been raised in this thread about smoothing the contribution requirements. However, I am still puzzled by the comments about the commit message format. Again, my inability to understand the issue does not mean I am not hearing. All the rules are not explicitly written, IIRC, so the most reliable way to adhere about the standard is probably to internalize these questions: What changes affected a particular source file? Was a particular source file renamed or moved, and if so, as part of wh= at change? What changes affected a given function or macro or definition of a data= structure? Was a function (or a macro or the definition of a data structure) renam= ed or moved from another file, and if so, as part of which change? What changes deleted a function (or macro or data structure)? What was the rationale for a given change, and what were its main ideas? Is there any additional information regarding the change, and if so, wh= ere can it be found?=20 https://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Lo= gs All in all, my only proposal would to have a Git pre-commit hook or some template pasting these questions and recalling the generic ChangeLog format, when writing the commit message. Maybe it would help=E2=80=A6 Cheers, simon