From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 0DqrK5KLFGTrzwAASxT56A (envelope-from ) for ; Fri, 17 Mar 2023 16:47:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id aFOHK5KLFGQIYwEA9RJhRA (envelope-from ) for ; Fri, 17 Mar 2023 16:47:30 +0100 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 511352A3BD for ; Fri, 17 Mar 2023 16:47:30 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=IyJs6p1H; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679068050; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=0zmhrGKvOO7A3SLPXghfaYwPzVu6k/eerk3uWlEOQWk=; b=PauU8eHsnpxC9lP10aTKC0KXldfWcUtS3eRyzhnohAao7P8y7754XXrutRyy80iuqh1BbL YfIYj65EF4OSTqyrXHP34uhxfYN2xVrryMhXMB34gF2SdKk5+DuK5mO1rjmz4LP0sdiVB9 XTCO4hV/lEnIrUZBL8gdtbpsIT38LeosMUrMtnxhEG3g8sjNEVsLoYK00fCxLTIp7Lpeug RPR9Hj4wul+5g6BBWGMI4Pe34hudmRaiqUMfJ5jXfkFdqe4xFdOqgUA6WyBokQXV+70VvM 7grcF3hkJEmXu10iIXujdsA5RNNG4jfGPXj0SpGU6QBpOG+AOe+M9yEhLiLhXg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=IyJs6p1H; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679068050; a=rsa-sha256; cv=none; b=SYOCTJvW15o/wjSLXNMfhQndJBzPPe+yjdKeOcHqcg9/OnbFXVW8AE5btTDISyXhDxOM3i b04FOqbp8QLT34l2fQxtQTSxsbZfW0+B1MGnCRhW1YIsBstLccQF3P7r4PLCpgLTOA1z0B KyOd+xEgNC9C581fA6hqdJ8H+zjfumA1MhF+ZD34VxguVGuTbZGSLF/E+9GGd+hbUjKnho 5aRRNLFTiPo4L6E4SUUeAOTDPqg4fuY2eOlkIbzF9pQZ0sRlKaDMUOU75evEpvAhHCB7AR a8G9C8pOiC3BqsUmXTd/+KLc0kvDFwfkh1J0bOx48jSiSnt0GqznDiW7EC+fSA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pdCIK-0000CZ-36; Fri, 17 Mar 2023 11:47:04 -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 1pdCII-0000CD-Di for guix-patches@gnu.org; Fri, 17 Mar 2023 11:47:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pdCII-0006VJ-2e for guix-patches@gnu.org; Fri, 17 Mar 2023 11:47:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pdCIH-00049b-RC for guix-patches@gnu.org; Fri, 17 Mar 2023 11:47:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#61894] [PATCH RFC] Team approval for patches Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 17 Mar 2023 15:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61894 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: guix-maintainers@gnu.org, Simon Tournier , Christopher Baines , 61894@debbugs.gnu.org, =?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?= , Andreas Enge , guix-devel@gnu.org Received: via spool by 61894-submit@debbugs.gnu.org id=B61894.167906800515944 (code B ref 61894); Fri, 17 Mar 2023 15:47:01 +0000 Received: (at 61894) by debbugs.gnu.org; 17 Mar 2023 15:46:45 +0000 Received: from localhost ([127.0.0.1]:45423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdCI0-000495-Nb for submit@debbugs.gnu.org; Fri, 17 Mar 2023 11:46:45 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:33304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdCHz-00048t-17 for 61894@debbugs.gnu.org; Fri, 17 Mar 2023 11:46:43 -0400 Received: by mail-qt1-f170.google.com with SMTP id n2so6073790qtp.0 for <61894@debbugs.gnu.org>; Fri, 17 Mar 2023 08:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679067997; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=0zmhrGKvOO7A3SLPXghfaYwPzVu6k/eerk3uWlEOQWk=; b=IyJs6p1HFJGEQJiOMZeZQpZcuUj/+9gl6cCQF2ysLMvKfg5Gm+ClqIIeN5U0yBnpHe liXpM4NKwKrw17nDvG7JNxo2RJNRURp085nSZWpA0Sl13VNHgyx9kb/JHSuqUXIjJEoH 4PiOPdqyYDsNnvC6hFdfmVpcAFBlw7OAKmg5c7twtH/q9h9DYTSb4C+x4jh/dONRHUEy nSr/RexbqAHC6X8ysPM+oYLjtZGg84V9wm0LSOVOYBg9ibZqiNgSEQlOjfvWFuM3BAnI 6buN42k8Qomv8aMraQxZVzUgIb9VU7t7yn6O4rQstnVaFunjAsJOuXrp3uEX0ogGVTm2 vwVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679067997; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0zmhrGKvOO7A3SLPXghfaYwPzVu6k/eerk3uWlEOQWk=; b=E9VfBCJhDCiDIWHOFbm9rPp9/8HZd9VlyjKut6MRs40ShpwqEWns2PDOUQV6EEg9Vh FbhrPCLZX6SPU6fROZR9EVjURUKps/5zMw53Wn4u7KBpkPruhJBi0xyeVzHTd5ms2SK/ YcRFEPjiBY0TjXWwIEgcvBUYGBIzy3ytZvvgisrlrt3DmvnT7/KcSGQFgPP6xK/Wvqhi CVi6fuE+IQXqT1N+nwAHqh5jEsG8N3RPY9TXmn3QPXFxzmoUJHsPkXgIIyxdXMKjuVxo fChX8A/avKuXG0sdoXLo1268/k0CIJ4WyDF9jVY0QQJ7zZvb/pDDTX9n31xw79rDAoQ3 Q6Vg== X-Gm-Message-State: AO0yUKUfJykMYWgG1dwiA5nYJzH3pUgBUrjRDvP+mMYyH3fsNbjKnxH+ AtD2ZaOv8R7pP0vZwxy1Rys= X-Google-Smtp-Source: AK7set+kOl29ZRIu9pLrOxERu3OaCvvewCyQV7bHKGPw29fp+qE2timL2hgfARlxmH8xqAVg9nRwpQ== X-Received: by 2002:a05:622a:1c3:b0:3bf:e39f:a9aa with SMTP id t3-20020a05622a01c300b003bfe39fa9aamr14064646qtw.27.1679067997458; Fri, 17 Mar 2023 08:46:37 -0700 (PDT) Received: from hurd (dsl-158-22.b2b2c.ca. [66.158.158.22]) by smtp.gmail.com with ESMTPSA id x26-20020ac86b5a000000b003bfa2c512e6sm1691991qts.20.2023.03.17.08.46.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Mar 2023 08:46:36 -0700 (PDT) From: Maxim Cournoyer References: <878rgga1qv.fsf@inria.fr> <871qm8wf8e.fsf@cbaines.net> <87r0u86qgo.fsf_-_@gnu.org> <87y1o9mina.fsf_-_@envs.net> <861qm0da4y.fsf@gmail.com> <87sfegwh28.fsf@gmail.com> <878rg7uqb4.fsf@gmail.com> <86lek6ntpb.fsf@gmail.com> <874jqtte7c.fsf@gmail.com> <87bkl0frnk.fsf@gnu.org> <87356ar6p1.fsf@gmail.com> <87bkku2e14.fsf@gnu.org> Date: Fri, 17 Mar 2023 11:46:35 -0400 In-Reply-To: <87bkku2e14.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Wed, 15 Mar 2023 17:08:23 +0100") Message-ID: <875yaz7544.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: X-Migadu-Queue-Id: 511352A3BD X-Spam-Score: -1.65 X-Migadu-Spam-Score: -1.65 X-Migadu-Scanner: scn0.migadu.com List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-TUID: idoV+A1F4e/L Hi Ludovic, Ludovic Court=C3=A8s writes: > Hello! > > Maxim Cournoyer skribis: > > [...] > >>> =E2=80=9CPacify=E2=80=9D in the sense that, by being explicit, we avoid >>> misunderstandings that could turn into unpleasant experiences. >>> >>> Like you I=E2=80=99m glad collaboration is nice and friendly; yet, over= the past >>> few months I=E2=80=99ve experienced misunderstandings that seemingly br= oke the >>> consensus-based process that has always prevailed. >> >> I'm sorry that you feel that way. I don't think consensus was willfully >> broken, > > That=E2=80=99s my point: by being explicit about approval, we would avoid= such > misunderstandings. > >> and perhaps by studying some actual examples of these occurrences we >> can better understand what went wrong and how the new suggested policy >> would have helped or could be modified to help avoid such problems in >> the future. > > I don=E2=80=99t want to rehash past occurrences of this problem. It boil= s down > to: changes where pushed despite consensus evidently not being met, at > least not in the mind of every involved party. > > To some extent, that=E2=80=99s bound to happen due to an increase of the = number > of contributors, scope of the project, and diversity of backgrounds. By > making it clear that lack of =E2=80=9CLGTM=E2=80=9D from another team mem= ber equates > with lack of consensus, we would avoid those misunderstandings. I agree that firm conventions here would make things smoother. It's common that someone offers an incomplete review or just forget the LGTM, and the author is left to ask if it's OK to push or not or assume it is. > A good reference on consensus-based decision making is > . > >> It's also worth noting that this consensus-based process has always >> been implicit; for example, it is not defined/mentioned anywhere in >> our documentation. Perhaps it should? > > Those who=E2=80=99ve followed the project long enough, such as part of the > current maintainer collective, are certainly aware of that; it=E2=80=99s = also > spelled out in > . > > That said, again in the spirit of improving legibility, writing it down > would be much welcome. Yes, I've heard 'consensus' for years, and I think I have a good enough understanding of it, but I think there are subtleties many (including myself) fail to appreciate that the above link explains well, so I think there's value in mentioning it somewhere. I'll send a patch for everyone to review. >>> In a way, that=E2=80=99s probably bound to happen as the group grows, a= nd I >>> think that=E2=80=99s why we must be explicit about what the process is = and about >>> whether one is expressing consent or dissent. >>> >>> With so many things happening in Guix (yay!), it=E2=80=99s also easy to= overlook >>> a change and realize when it=E2=80=99s too late. By having a rule that= at least >>> one other person on the team must approve (consent to) a change, we >>> reduce that risk. >>> >>> Being on a team, then, is a way to express interest on a topic and to be >>> =E2=80=9Cin the loop=E2=80=9D. >> >> That's already what teams can do! > > Yes and no. With the amount of activity going on, it=E2=80=99s easy to o= verlook > something. The explicit synchronization point could mitigate that. > >> I'd argue giving them the extra powers that would be conferred to >> teams in this is not needed/desirable. Some committer not a regular >> member of X team may still be confident enough to push a patch sitting >> on the tracker, and I think they should be able to. > > Self-assessment becomes tricky that this scale; I might be confident and > yet someone will point out a problem (that literally happened to me two > days ago in ). That=E2=80=99s when re= view > really helps. > > For =E2=80=9Ccore=E2=80=9D work, I insist that explicit approval (and thu= s peer review) > is necessary. I doubt anyone would seriously challenge that. > > Now, I agree, as I wrote before, that this may be overkill for =E2=80=9Cr= andom > packages=E2=80=9D. > > Thus we need to find the right balance. > > What about team/scope-specific rules? As in: =E2=80=9CChanges covered by= teams > X, Y, and Z need to be explicitly approved by at least one other member > of the team.=E2=80=9D To me, it seems challenging to partition the code correctly and avoid overloading the core team with spurious changes, which would slow things down more (as the core team would be a fraction of the committers currently enabled to push such changes), but I agree in principle that it makes sense. >>> It is not about asserting power or building a hierarchy; >>> it=E2=80=99s about formalizing existing relations and processes. >> >> OK; I think in practice it would amount to that though (building a >> hierarchy which has some form power). > > I disagree: just because power relations are not spelled out doesn=E2=80= =99t > mean they don=E2=80=99t exist. I don=E2=80=99t know where you=E2=80=99re= talking from; one > thing that to me shed light on these matters is =E2=80=9CThe Tyranny of > Structurelessness=E2=80=9D (I=E2=80=99m sure I mentioned it before, I cer= tainly did > during Q&A on this very topic at the Ten Years event; apologies if I > sound like a broken record!). As with anything there's probably a middle ground to reach, where there's some structure, but not too much, that maximizes our collective happiness. --=20 Thanks, Maxim