From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 0BUtBgSsgWUmwgAAkFu2QA (envelope-from ) for ; Tue, 19 Dec 2023 15:43:16 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 0FZJAwSsgWXkRgEA62LTzQ (envelope-from ) for ; Tue, 19 Dec 2023 15:43:16 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NbOCgJi3; 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=1702996996; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=YoJe3G9NscSiK1GNZZEtG8Qgfss4EmxuQCIe8YpyQd8=; b=i0gQ7cMjI9Bo9GDwznLd6fUjIrhr3QliTJqyUvi9zLnPJcldJH1vZQok/yiHiSD4tSQ6a5 aySg6FgS69Jr2GJ8pY5+5WveDYp8xPlEnqUrxb11u58OfQ09hC7FdjdQiP9pEAC6u2Mb+j C12Y4KYSacqd2hBZUWqPNqYufz3znn50WXAMWAlFktPNtZdIlAQDQo1NnnNfhnbArcVymh VkEyGDkwXgomlRdb7SZdGovAbGIrC+DgErdXPkqKhl9/dbKMZ8w6/0LHq0d17hyLBCKnvi TULS/VoV8igSymheMeBqCIeeCx17MIYWdIFI4xw65tEovVhV2fLWIPLj2JFt0w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1702996996; a=rsa-sha256; cv=none; b=u9XS5HwkgIQcKzvGZpWel2TrOqJS+egIREjeoFGn74+BqlQ/hTwuX/nLz1Is39AeFGHPcW tRgeauLIIR8+c4mbXHyQYxLZBmLkynEDoRjX1AgqVyrvparH+hC8ZzmHYn3J2JxKDhX4F3 85tWdWfYOKkrapZj+tD6ZYoWtreUhD0zZG8fet86knxRITXdu41VLPJSgKpvifqhbgHUAW Zd0ghAQCea5v/vCBrwi2WsDYR/aC8V9+QjzRNO/DHe2OnwjwpMcYqi3uK2iQRfaAVE6Moi Al3H7bmRmPfFm5Ya5bktF/IUEFN/7U5lXVLzk96LPjWQNJ3J/kF6dq+mw40n/g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NbOCgJi3; 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 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 D1FEE35399 for ; Tue, 19 Dec 2023 15:43:15 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rFbJ4-0003L5-S4; Tue, 19 Dec 2023 09:42:50 -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 1rFbJ2-0003Kx-KP for guix-devel@gnu.org; Tue, 19 Dec 2023 09:42:48 -0500 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rFbJ0-0003vo-G6 for guix-devel@gnu.org; Tue, 19 Dec 2023 09:42:48 -0500 Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-33626a5cf2bso555819f8f.0 for ; Tue, 19 Dec 2023 06:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702996965; x=1703601765; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=YoJe3G9NscSiK1GNZZEtG8Qgfss4EmxuQCIe8YpyQd8=; b=NbOCgJi37NpiJy+BmdTxur0wsmfEMdw3/RBxA6JKu4hkyk6n4rfd2fdjFAtp1q9Zj1 2yZS6o2QuIkpEdQmHM8mSQLp5dmX54svg3s/Tg4npfHffb+Jb+fQs/WOZGgWVcWuJLa3 jS9lfjKlEjo1OV4TVr6AcoAVAr9lCUgQlZPrX4eqNaefnMSVJbaQTZC509hCQDVix3Hw VvEsaIbdLf+NKNU3EGPVaRZj+GwQJM01nYwyTZRfGLWINiCEGVMpTtvK3Qv/uALSuR/K XJsBLt/dNzVajvKgJ1mkM21hd7Ed/MNUlqi5HP3YWkomS1c2M8LMn7+m7SfLr7GF5PsI lmzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702996965; x=1703601765; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=YoJe3G9NscSiK1GNZZEtG8Qgfss4EmxuQCIe8YpyQd8=; b=LQsGfgzS45l+4TjNz5AKoGXEyqy242Dwmv8ELNlD4XgYa3rKWpBo0XLlncxcatvJ8u 0m1B8bjl00n+7xOCs/9b55O2aKoE2uc+oJtq1jkRxW9xhSrWf9nPcSl2lESkK2FKcUwT xpF48rErHI8V++335WtICBcwYR9GomUcwGwsvDxIqt4geAOQcz44NawsANzrEP5QH6Le akzuwcg0wzEFkdeNnHpkWKeJf7Eas719wM9PSy9lTKo8vCx3ELNAwkSDQixcwW6ZChA3 4Ria1N30ZWjAcJUQMOrrQQTj9XHmGV5BmHw+hrMFfUPML5EOw9Mw6XkDpX/7YRlb52YL bx4A== X-Gm-Message-State: AOJu0Yz5HIJb+WK1cT4utkSQTwdxV3biibL3+kHtze9HjiiOrM1sPpCW iQtB0qmulxJGvuVZYzA8NcJsky1l1V0= X-Google-Smtp-Source: AGHT+IFxzt4KFTmlX+E8yKJNflNJryp9tYAvSy5v8cHM7Ml80ppa7RbWmgLZARMO0rv1tGBuzuco5g== X-Received: by 2002:a5d:47c9:0:b0:333:460f:758a with SMTP id o9-20020a5d47c9000000b00333460f758amr22553278wrc.7.1702996964773; Tue, 19 Dec 2023 06:42:44 -0800 (PST) Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id c6-20020a5d4cc6000000b0033662c2820bsm7564245wrt.117.2023.12.19.06.42.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 06:42:44 -0800 (PST) From: Simon Tournier To: Guix Devel Subject: Re: Request-For-Comment process: concrete implementation In-Reply-To: <87h6m7yrfh.fsf@gmail.com> References: <87h6m7yrfh.fsf@gmail.com> Date: Tue, 19 Dec 2023 13:33:55 +0100 Message-ID: <87v88u4bik.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::433; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x433.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, T_SCC_BODY_TEXT_LINE=-0.01 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.54 X-Spam-Score: -9.54 X-Migadu-Queue-Id: D1FEE35399 X-Migadu-Scanner: mx12.migadu.com X-TUID: 1tDwcntymfEl Hi, Well, more than 7 weeks later=E2=80=A6 Hum, does it mean that the Guix proj= ect is not interested in formalizing some RFC? WDYT about the proposal? On Tue, 31 Oct 2023 at 12:14, Simon Tournier wro= te: > Hi, > > This is a proposal for implementing Request-For-Comment process. > Comment are welcome in #66844 [1]: > > 1: https://issues.guix.gnu.org/issue/66844 > > > The proposal is highly inspired by Rust RFC: > > https://github.com/rust-lang/rfcs > > and also by GHC Haskell proposal process [1] and Nix RFC process [2]. Ba= sed > on my understanding of Guix community interactions, I write down this > text; below the text for easing the reading. > > Cheers, > simon > > 1: https://github.com/ghc-proposals/ghc-proposals > 2: https://github.com/NixOS/rfcs > > -- > > RFC process > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > # -*- mode:org -*- > #+TITLE: Request-For-Comment process > #+DATE: 2023-10-31 > > + Issue: 66844 > + Status: pending > + Supporter: Simon Tournier > + Co-supporters: > > * Summary > > The "RFC" (request for comments) process is intended to provide a consist= ent > and controlled path for new features to enter the Guix project, so that a= ll > stakeholders can be confident about the direction it is evolving in. > > * Motivation > > The freewheeling way that we add new features to Guix has been good for e= arly > development, but for Guix to become a broadly used system we need to deve= lop > some more self-discipline when it comes to changing our beloved system. = This > is a proposal for a more principled RFC process to make it a more integral > part of the overall development process, and one that is followed consist= ently > to introduce substancial features. > > There are a number of changes that are significant enough that they could > benefit from wider community consensus before being introduced. Either > because they introduce new concepts, big changes or are controversial eno= ugh > that not everybody will agree on the direction to take. > > Therefore, the purpose of this RFC is to introduce a process that allows = to > bring the discussion upfront and strengthen decisions. This RFC is used = to > bootstrap the process and further RFCs can be used to refine the process. > > Note that this process does not cover most of the changes. It covers > significant changes, for some examples: > > + change of inputs style > (Removing input labels from package definitions, #49169) > + introduction of =3Dguix shell=3D and deprecation of =3Dguix environmen= t=3D > (Add 'guix shell' to subsume 'guix environment', #50960) > + introduction of authentication mechanism (Trustable "guix pull", #2288= 3) > + massive Python 2 removal > (Merging the purge-python2-packages branch, mailing list guix-devel) > + collaboration via team and branch-features > (several places mailing list guix-devel) > > * Detail design > > ** When you need to follow this process > > This process is followed when one intends to make "substantial" changes t= o the > Guix project. What constitutes a "substantial" change is evolving based = on > community norms, but may include the following. > > + Any change that modifies Guix API > + Big restructuring of packages > + Introduction or removal of subcommands > > Certain changes do not require an RFC: > > - Adding, updating packages, removing outdated packages > - Fixing security updates and bugs that don't break interfaces > > A patch submission to Debbugs that contains any of the afore-mentioned > substantial changes may be asked to first submit a RFC. > > ** How the process works > > 1. Clone https://git.savannah.gnu.org/git/guix.git > 2. Copy rfc/0000-template.org to rfc/00XY-good-name.org where good-name= is > descriptive but not too long and XY increments > 3. Fill RFC > 4. Submit to guix-patches@gnu.org > > Make sure the proposal is as well-written as you would expect the final > version of it to be. It does not mean that all the subtilities must be > considered at this point since that is the aim of review discussion. It = means > that the RFC process is not a prospective brainstorming and the proposal > formalize an idea for making it happen. > > The submission of a proposal does not require an implementation. However= , to > improve the chance of a successful RFC, it might be recommended to have an > idea for implementing it. If an implementation is attached to the detail= ed > design, it might help the discussion. > > At this point, at least one other person must volunteer to be "co-support= er". > The aim is to improve the chances that the RFC is both desired and likely= to > be implemented. > > Once supporter and co-supporter(s) are committed in the RFC process, the > review discussion starts. Advertisement of the RFC on the mailing-lists > guix-devel is mandatory and IRC is recommended. > > After a number of rounds of review, the discussion should settle and a ge= neral > consensus should emerge. If the RFC is successful then authors may contr= ibute > to the implementation. This bit is left intentionally vague and should be > refined in the future. > > A successful RFC is not a rubber stamp, and in particular still does not = mean > the feature will ultimately be merged; it does mean that in principle all= the > major stakeholders have agreed to the feature and are amenable to merging= it. > > An unsuccessful RFC is *not* a judgment on the value of the work, so a re= fusal > should rather be interpreted as =E2=80=9Clet=E2=80=99s discuss again with= a different angle=E2=80=9D. > The last state of an unsuccessful RFC is archived under the directory > rfcs/unsuccessful/. > > ** Co-supporter > > A co-supporter is a contributor sufficiently familiar with the project=E2= =80=99s > practices, hence it is recommended, but not mandatory, to be a contributor > with commit access. The co-supporter helps the supporter, they are both > charged with keeping the proposal moving through the process. The > co-supporter role is to help the proposal supporter by being the timekeep= er > and helps in pushing forward until process completion. > > The co-supporter doesn't necessarily have to agree with all the points of= the > RFC but should generally be satisfied that the proposed additions are a g= ood > thing for the community. > > ** Comment period > > It is up to the supporter and co-supporter to ensure that sufficient > discussion is solicited. Let two weeks for people to comment is a good > average. Make sure that all have the time for expressing their comments.= The > proposal is about significant changes, thus more time is better than less. > > ** Decision making: consensus > > It is expected from all contributors, and even more so from committers, to > help build consensus and make decisions based on consensus. By using > consensus, we are committed to finding solutions that everyone can live w= ith. > > It implies that no decision is made against significant concerns and these > concerns are actively resolved with proposals that work for everyone. A > contributor, without or with commit access, wishing to block a proposal b= ears > a special responsibility for finding alternatives, proposing ideas/code or > explaining the rationale for the status quo. > > To learn what consensus decision making means and understand its finer > details, you are encouraged to read > . > > ** Merging the outcome > > Whoever merges the successful RFC should do the following: > > 1. Fill in the remaining metadata in the RFC header, including links for= the > original Debbugs submission. > 2. Commit everything. > > ** Template of RFC > > The structure of the RFC is captured by the template; see the file > rfc/0000-template.txt. It is recommended to write using markup language = as, > for example, Org-mode or Markdown or reStructuredText. > > ** Backward Compatibility > > None. > > ** Drawbacks > > There is a risk that the additional process will hinder contribution more= than > it would help. We should stay alert that the process is only a way to he= lp > contribution, not an end in itself. > > Of course, group decision-making processes are difficult to manage. > > The ease of commenting may bring a slightly diminished signal-to-noise ra= tio > in collected feedback, particularly on easily bike-shedded topics. > > ** Open questions > > There are still questions regarding the desired scope of the process. Wh= ile > we want to ensure that changes which affect the users are well-considered= , we > certainly don't want the process to become unduly burdensome. This is a > careful balance which will require care to maintain moving forward. > > * Unresolved questions Cheers, simon