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 mNTlGwL5/mTIKAEA9RJhRA:P1 (envelope-from ) for ; Mon, 11 Sep 2023 13:24:50 +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 mNTlGwL5/mTIKAEA9RJhRA (envelope-from ) for ; Mon, 11 Sep 2023 13:24:50 +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 D3D0F32805 for ; Mon, 11 Sep 2023 13:24:49 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=SOLgHeAy; 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=1694431490; 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=BXtnekeGgVsJiKyn5pM8C78pvhOPwynW1zYEkUAPq+M=; b=PVaIc3TmiUSIjC9JXrqmZErlPzCwkpQxvcz9se7GUNrARmR24Zml+bj6wJOyL9vOzFTU9g kI8aWLd75eneaHyxXcviQsY2MHxO7yXpBI2TrJUUc3PZl+P6quTe/JAHv5EXoWd4K+lh5g 1K0fFfHPKdhqfKwZBBUU6x04z3NZ+Bdi8TlIIwcJMeFw9KU5PIsbN2qY4GMXsjWM1ui/69 3jscwIg6NTqs7LoYprWtk5uZex/lSfYCWhrgC2zahRs/40yeiJKq914SuiN6Bf9AkdyagP dRWN+eGgI2G2M5jZ2HaNEZSjethzUEGVWTosE8Bb+KoBaX/ndSI2hm2rRoxMOA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694431490; a=rsa-sha256; cv=none; b=P2p6DKThOxgri3l+LpuEywilXLsPFuLLpai0xjZBJFGnaMDB2w1iStLo+Ca2RXfwGoFUyh 1EIBetQl7mw25odNLMQsi27gakgcTL2yXK61ttOvLrR1JA2NED3U0E6MC2Kb/XYWxEVWM9 Oge5ZHWUMLEcpRNEWTZwZUdZUnM9TrOgiuiGVuBArDtHuKI16WALGxxCL/K4tUb9+hNUJT cL+Vu2P2//jYzh8ljaIV+kKdwG9XkD8HD+pwtTpDnvybGhSkZxJH4QsPUpJ73r/GlZsdHf xCeq2B+YCGtrH1CUu+9CYZAwEiVDr35cwm92EhDz34lUQ99uU7ul8njUgjVKtw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=SOLgHeAy; 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 1qff1V-0004Ru-Q0; Mon, 11 Sep 2023 07:24:09 -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 1qff1S-0004Pt-KK for guix-devel@gnu.org; Mon, 11 Sep 2023 07:24:06 -0400 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qff1Q-0006qQ-9e for guix-devel@gnu.org; Mon, 11 Sep 2023 07:24:06 -0400 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-401314e7838so13921355e9.1 for ; Mon, 11 Sep 2023 04:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694431442; x=1695036242; 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=BXtnekeGgVsJiKyn5pM8C78pvhOPwynW1zYEkUAPq+M=; b=SOLgHeAyMLL7EzlNtX6JbrgCwxqk3WQsLOh5M0s9lN8GOplsFXwMjU38RVUIGW3u78 e5SznNsmBMtKSFiWaXuCu6+CLOLD0SeB4JbVwcsRIiv90yxbdvWxIpiYWaSMBksVpNhZ wBg7N+uiY+RBjyX/eYfpJr73zygT4c65xklDRdch4/SZzKb/A4FD2kP/oj3BohogUhjt hmF+vU3xCDFyykhzMMqvX3gTKhFeLg7YC8dU0vb86oAGOwHpLdsR4bbGt+Eau8nDoxF/ GW/z2nCbXyLJ6dJBoCXdiQUfj4lAtyT/3GKLrACCDWM1r2GgLFRqtrdYCIO4L3Jw9GIX 9hBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694431442; x=1695036242; 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=BXtnekeGgVsJiKyn5pM8C78pvhOPwynW1zYEkUAPq+M=; b=Fn//+ZcwHJdzlWApqXl5ZivmdtXoSQERqm3n5wZ70wh9NaZerTiBker4sWL+P1tQgw oh4tlEhOGjJvQpkm8auV+kSPj9uQlo5eAjJSRLG+tpjJmMuQuA7OItYWoP926NZfQwc5 uoyg7QnjEwWWj8zQOSuzYiVV9VQNJtPjkQ3Nygm5O1DZ/YR5/WryrqFB0fnvJmVSPcL+ RVF4FJ6tAiT5a4HuAKFwsyjAR6SywNjKzV8VAFonMlmBYKrSjXobgOw+jMPbOr8trgHL SebFcPgpILuiUkMbBslPqVKM2pcYbfep2dldAVyeusara75UzfvcEcqvD5WBe/Int1ch rb9Q== X-Gm-Message-State: AOJu0Yxz4AVITSXSmGgeIXRbOjAa7GbRKzIHw8TduMzpgo/DZEYdDHrN 33NDOcm1TrdiT6zjT2CzAYLe2hxsL4s= X-Google-Smtp-Source: AGHT+IHLUIRqlI06UGWS6n2GFkry9JUxoMjYpkzlu6WFhA8KErjY1fqfWffX6yOBAC2Uz1mQlcagjA== X-Received: by 2002:a05:600c:1c98:b0:401:c07f:72bd with SMTP id k24-20020a05600c1c9800b00401c07f72bdmr8724486wms.4.1694431442537; Mon, 11 Sep 2023 04:24:02 -0700 (PDT) Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id p4-20020a7bcc84000000b003feef82bbefsm9680704wma.29.2023.09.11.04.24.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 04:24:02 -0700 (PDT) From: Simon Tournier To: Liliana Marie Prikler , Ricardo Wurmus Cc: Attila Lendvai , Andreas Enge , Katherine Cox-Buday , guix-devel@gnu.org Subject: Re: How can we decrease the cognitive overhead for contributors? In-Reply-To: References: <87sf7o67ia.fsf@elephly.net> <9269133a74e06bfc5ee5bfeee0342ba2f5beaeb1.camel@gmail.com> <87tts44d2y.fsf@elephly.net> <4c85b742e29ebbf7fe3cde3f72961269ec26218c.camel@gmail.com> <87cyyr3zdc.fsf@elephly.net> Date: Mon, 11 Sep 2023 12:36:04 +0200 Message-ID: <87fs3lj8tn.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::32d; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x32d.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: mx0.migadu.com X-Migadu-Spam-Score: -0.11 X-Spam-Score: -0.11 X-Migadu-Queue-Id: D3D0F32805 X-TUID: BHSU2/eTPkJQ Hi Liliana, On Sun, 10 Sep 2023 at 00:20, Liliana Marie Prikler wrote: >> > > Must we force a single workflow on everyone, even if our track >> > > record in reviewing and merging doesn=E2=80=99t clearly show that ou= r way >> > > is superior >> > >> > Again, define superior. >>=20 >> No, I won=E2=80=99t.=C2=A0 I think it=E2=80=99s obvious that our review = process isn=E2=80=99t >> working *well*.=C2=A0 So the argument that our current workflow allows f= or >> effective review is dubious.=C2=A0 Not saying that you made that claim, >> just that it=E2=80=99s hard to convince others of adopting our ways when= the >> results just aren=E2=80=99t great. > > What do you consider "the results" here? The rate at which patches are > merged? This is hardly an issue our project alone is fighting and I'm > not convinced that technology, more or less, will shift it in either > direction.=20=20 That=E2=80=99s not about =E2=80=9Cresult=E2=80=9D here. That=E2=80=99s abo= ut =E2=80=9Csimple vs easy=E2=80=9D or =E2=80=9Ccomplex can be easy=E2=80=9D or etc. Similarly as submitting patches means that many steps are more or less simple, then the complete process can be considered as relatively complex. To be explicit, I do not speak about being =E2=80=9Ceasy=E2=80=9D= which is subjective and instead I am speaking about some objective criteria (e.g., the number of steps even if they are trivial). Some part of that complexity has some value for the project and some other part has no value. The question is thus to identify and then remove (or hide) the complexity that has no value for the project. Today, the review and commit process have many steps, more or less simple, not all sure!, well at the end, we have something complex. One trivial step is to apply the patch (or series) to your local checkout and so many things can lead to some useless frictions. For example, the patch does not apply because the base commit is not provided, or because it is badly formatted, or because=E2=80=A6. And one e= nds to fix themself, e.g., probably using some manual trick just for applying the patch. No value for the project. Yes, QA is currently helping for that specific example about applying patches but the solution depends on why the patch does not apply. Well, I am not saying that we should switch to PR model using GitHub. :-) Let just recognize that our current workflow has many drawbacks that make some frictions (steps with no value) for reviewing. And PR model =C3=A0 la GitHub has many other drawbacks but at least it reduces some frictions (technical steps with no value); mainly because some people are paid for removing (or hide) these useless friction. Don=E2=80=99t you agree that the review process implies many manual steps t= hat have no value for the project? Last, I agree that the main issue when speaking about the reviewing process is not about tooling. The lack of a smooth technical solution is just acting as a chemical developing solution in photography, it increases the contrast and makes the poor image apparent. Cheers, simon