From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id wvszM1cLBmTRbgAASxT56A (envelope-from ) for ; Mon, 06 Mar 2023 16:48:39 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id mGpDMlcLBmTOgQEA9RJhRA (envelope-from ) for ; Mon, 06 Mar 2023 16:48:39 +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 B85073E1D8 for ; Mon, 6 Mar 2023 16:48:39 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZD4U-0003D9-3S; Mon, 06 Mar 2023 10:48:18 -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 1pZD4S-0003Ag-8E for guix-devel@gnu.org; Mon, 06 Mar 2023 10:48:16 -0500 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pZD4Q-0004s1-7d; Mon, 06 Mar 2023 10:48:15 -0500 Received: by mail-qt1-x832.google.com with SMTP id y10so11010382qtj.2; Mon, 06 Mar 2023 07:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678117691; 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=EWjK/ji4NdizPMEp6fIRCOoqH+FTcAithgn2iNVyW2Y=; b=IoPEGZuqp4/uSy6k2Y5YJJ5/fnqlOOBGJHsvGCnbLDVP/08PkVPuRsQ68dH70Na5ly CoKC8vXsf6c+Vl7gXaB7J2mif6fko6iEilzSwp+bmQrcywnjXsp24N1VI1GqIOtYA/Ei lcBeKKc4ZS/87wDtBaxAIdOLzoHtW7rg+BNloChFBrqdsGcx1Q7zd3g++1DuCHYiQa2e fiBhnfHSwCacGpw9WIGVwPI//eqkRSP93rssP9XT0gPvBZkviro9xOBHPocPIAPTN5wD pBCtmyvVVs7FEtiBpLrb3uUQvMKjCjhZVIcqwN9zITDMGznC8OKr/rZqlYRDiSCQxN1H b4Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678117691; 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=EWjK/ji4NdizPMEp6fIRCOoqH+FTcAithgn2iNVyW2Y=; b=H8ltI66lvCtBc5Ab2cCawifDy/oB6S99RWw2xz3qHrBcFiKSMt+L0L6viGOAno5ShM xAqshLsJfJhres30viEe2ontaQuKtYg2oVfK3NiAw7zoIN8KI7HNWcClStEVOi65A7Sn qL1M7nJg0s36dnHn3428s2JGZd07DOfRlhI62DGHIvcvMjYpw9Fvdlvq476hTOoXDDuB /Wm+rcF3FxDTwDwjeLGvjzZjHhFWuCvzxlYPkCpbyEhirtGneyFubUOAYvvyexyiqI1n D7pXfq96s/9cJ+Zv7NR84Br7MmK6w2PhJpSuqb/6tYvBoHKhItUx1tAmwrNgz2xIuoaN 5GVg== X-Gm-Message-State: AO0yUKUva2j6SWBySbHUsFw4JnTxGUf9jjZo0DMLEAVqqE4SKvVixv9n XcDbf2CbR1SCf8VRAHKkWMCj2BuApd4wIQ== X-Google-Smtp-Source: AK7set9+a/ipoMSIdte3TZ5oLYo4rbeq8/XamUgLz6z9vxT4VcQzHTkxcl5nB02IYoYUAJ5Aelvvig== X-Received: by 2002:ac8:5f92:0:b0:3bd:1728:8886 with SMTP id j18-20020ac85f92000000b003bd17288886mr17229999qta.9.1678117691568; Mon, 06 Mar 2023 07:48:11 -0800 (PST) Received: from hurd (dsl-149-144.b2b2c.ca. [66.158.149.144]) by smtp.gmail.com with ESMTPSA id j11-20020a05622a038b00b003bd0f0b26b0sm7925021qtx.77.2023.03.06.07.48.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Mar 2023 07:48:11 -0800 (PST) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: 61894@debbugs.gnu.org, guix-devel , guix-maintainers@gnu.org Subject: Re: [bug#61894] [PATCH RFC] Team approval for patches References: <878rgga1qv.fsf@inria.fr> Date: Mon, 06 Mar 2023 10:48:10 -0500 In-Reply-To: <878rgga1qv.fsf@inria.fr> ("Ludovic =?utf-8?Q?Court=C3=A8s=22?= =?utf-8?Q?'s?= message of "Wed, 01 Mar 2023 17:13:28 +0100") Message-ID: <87h6ux285h.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 Received-SPF: pass client-ip=2607:f8b0:4864:20::832; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qt1-x832.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-TUID: Lu8bG/UTG5wN Hi Ludovic, Ludovic Court=C3=A8s writes: > Hello Guix! > > The project has been steadily gaining new contributors, which is great, > and I think we need to adjust our processes accordingly. > > Currently teams are described mostly as pools of people who can mentor > contributors in a particular area and who can review patches in that > area. My proposal is to give teams formal approval power over changes > to code in their area. > > This is sorta happening already, but informally: if a non-committer > sends a patch, someone from the team eventually =E2=80=9Capproves=E2=80= =9D it by pushing > it. Within a team, the situation is different: people usually discuss > changes, and the submitter (also committer) eventually pushes them; > sometimes, the submitter pushes changes without getting approval (or > feedback) from others on the team. > > With the proposed policy, members of a team would also have to review > and approve each other=E2=80=99s work. Formal approval means getting an > explicit =E2=80=9CLGTM=E2=80=9D (or similar) from at least one other team= member. > > This is similar to the review thresholds found on GitLab & co., where > project admins can specify a minimum number of approvals required before > a change is marked as ready. I think it avoids the unavoidable > misunderstandings that can arise in a growing group and help pacify > day-to-day collaboration. > > Below is a suggested change. > > What do people think? > > Ludo=E2=80=99. It sounds reasonable and a good change "on paper", but in practice I think it may be too soon to formalize teams that way. Teams are a nascent concept which hasn't reached a point we can rely on it, in my opinion. We are still ironing out kinks in the tools [0] :-). I'd prefer we stay as nimble/agile as we can and maximize the potential of our large committers pool for now, at the expense of sometimes having to retroactively discussing/fixing up or reverting some change that wasn't up to par, that could have possibly been caught by a more focused team. [0] https://issues.guix.gnu.org/58813 --=20 Thanks, Maxim