From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id yOH1N8HhQGV3cwAAauVa8A:P1 (envelope-from ) for ; Tue, 31 Oct 2023 12:15:14 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id yOH1N8HhQGV3cwAAauVa8A (envelope-from ) for ; Tue, 31 Oct 2023 12:15:13 +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 8A42A6402C for ; Tue, 31 Oct 2023 12:15:13 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ev6NTGsS; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1698750913; a=rsa-sha256; cv=none; b=QsubbOnucwr1pN1qbfZqxG9ILDRoew1b511afVMnoXcU+biJqYv+ZbZCgu/WO2MmYy9A3c fvLIJ1Kg6yafCQKCYNQYub3rV2UO/QfIYY9ZZ9BFjLOMFnNQN4pAcTu5m8Qd8+69ngBsbG +eDo0De0IUBNgSr8i3PPb3//n2WmWH9xEWhjazwsw3xDQ63fDMjkau31C7mSVY4CdBr/cp WKvJJ+HFww7DonDJZ0KDJeINE4/OMhpt4cRA2vjE6mpLRULE5Y3KBRUVMJ0j95PWy2mnXf +M1l26bw2nSKF0IKVko9WMXDVhnJwaRc2iKMu/UzlFAx/aE2j8NMHpJTqJxuuw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ev6NTGsS; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1698750913; 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:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=yYndxotNhPfIj4KP5X/hvtkkNVyM59wO1rVM2iD+zZ4=; b=lTvFLBCZyykXKpKREDDXLo1Jv7vFTikB6XPdmz1ynVJdl4NJy7FVe2xfiIVtDxeehuJSbI DkE2SsKl3kbF7rRCGHTbn2th2x2ZfDnMKini6b+TFMmpY2fb1FDoQG/yx4gnL+i/GoFZjX bzQbzhtNJgEAhWPnxMZgxkcs6tQD7M84sbdlD0vTf79Ynxe+SCWsPczL+02ekz8ibQybkc GFH2dqaye2IMitAbV28XPY5iSO+t3An4AB1E7kZqzrj1qTXCOQf0F+p8HcNL4kestQLegP QzOFNZmhWjzJTIMlsqCaXYZRc1r0/bC5Vl/dSAg3Iy1KmbD6zN2wZab6835SlA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qxmhx-0002yt-Ev; Tue, 31 Oct 2023 07:14:53 -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 1qxmhu-0002wZ-7T for guix-devel@gnu.org; Tue, 31 Oct 2023 07:14:50 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qxmhr-0007wD-P4 for guix-devel@gnu.org; Tue, 31 Oct 2023 07:14:49 -0400 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-32f8246103cso558729f8f.1 for ; Tue, 31 Oct 2023 04:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698750886; x=1699355686; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=yYndxotNhPfIj4KP5X/hvtkkNVyM59wO1rVM2iD+zZ4=; b=Ev6NTGsS30xsEESgpB6adoYI86Sii6dFUhy7wkZiJf9GVm3kLhTZ2RIHOTJXeVPyQZ OxPkUSkxnwn1cqQvNAu3f1v1iZFt0OdVsCRsp3Jw3WRSqr72gIWhMo2axCkO/fOA4pT5 ReKXL0kUXBSZCP5iJ/7HSg0rh9r6+VjzvGBmGRMdUE/pU0I0mitX6V5fTIqOIiZzQ5r3 Grbu/O/n8CodrfQpVsGMLeose/1zUOkVHK1LxybK00dvqRuAIsYG9V30nRRvAVtfFJIl W4eI5ApAyHQncnQy17wU8t8VRU1RGtoxJ9p91G+EFs1W17Oq4Y0lFRYxETUQT+pRDCBy cvQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698750886; x=1699355686; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yYndxotNhPfIj4KP5X/hvtkkNVyM59wO1rVM2iD+zZ4=; b=EAWGqA3UzLV6PvFqVKujTD4drUCKt79GZDBzqyFgshnrGKwycsSP7Q6tVsTRyYLKDv e0RGo/q+ElyOO/gkAxiBRs/MSe52n0+VL0ZgA2oefpBZm/vOImdKPiMbWCxWjDmwh47X qWn7zZWeUiwLIaoCAQQpYSDsrb2hjKieBoKcxDk5PWpTP2ByY9OrQQTIDrqeMC0Xa2tQ YZDnQcCDb4TAP021NOQHzO36GZedBwf3s8rnptr64wF6PW+vKWEp0+51qkbtGIei/egT /ntQ3wytW+sbAUhOTYacZOSwAkxpxBsR33YoAthWRoB/V6GW+dw8lL84HU1Ngnrzldwm BoCw== X-Gm-Message-State: AOJu0YyRq8u9xO+OG+5bP+XoB/XeS5jsx4/iCgU3i8AhhJablEfVwy9K JTWYdv8n0Ykn1d+jNqdPLiVfLJnK5eY= X-Google-Smtp-Source: AGHT+IEuwU46Hp8F1oJmjY7646pbP2QZgZCIqp9tEd3y7SQPhDCDLvBRdMFEXmrwV0GvZ4VA7121Qg== X-Received: by 2002:a05:6000:8f:b0:32f:89c0:95d8 with SMTP id m15-20020a056000008f00b0032f89c095d8mr3293965wrx.3.1698750885828; Tue, 31 Oct 2023 04:14:45 -0700 (PDT) Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id n6-20020a5d67c6000000b00323293bd023sm1274861wrw.6.2023.10.31.04.14.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 04:14:45 -0700 (PDT) From: Simon Tournier To: Guix Devel Subject: Request-For-Comment process: concrete implementation Date: Tue, 31 Oct 2023 12:14:42 +0100 Message-ID: <87h6m7yrfh.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::42b; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x42b.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-Queue-Id: 8A42A6402C X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.41 X-Spam-Score: -9.41 X-TUID: 0mWX3YcXIALF --=-=-= Content-Type: text/plain 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]. Based 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 =========== --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline; filename=0001-rfc-process.txt Content-Transfer-Encoding: quoted-printable Content-Description: rfc.txt # -*- 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 consistent and controlled path for new features to enter the Guix project, so that all 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 ear= ly development, but for Guix to become a broadly used system we need to develop some more self-discipline when it comes to changing our beloved system. Th= is 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 consisten= tly 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 enough 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 environment= =3D (Add 'guix shell' to subsume 'guix environment', #50960) + introduction of authentication mechanism (Trustable "guix pull", #22883) + 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 to = 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 me= ans 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 detailed design, it might help the discussion. At this point, at least one other person must volunteer to be "co-supporter= ". 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 gene= ral consensus should emerge. If the RFC is successful then authors may contrib= ute 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 me= an the feature will ultimately be merged; it does mean that in principle all t= he major stakeholders have agreed to the feature and are amenable to merging i= t. An unsuccessful RFC is *not* a judgment on the value of the work, so a refu= sal 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 timekeeper and helps in pushing forward until process completion. The co-supporter doesn't necessarily have to agree with all the points of t= he RFC but should generally be satisfied that the proposed additions are a good 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 wit= h. 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 bea= rs 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 t= he 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 t= han it would help. We should stay alert that the process is only a way to help 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 ratio in collected feedback, particularly on easily bike-shedded topics. ** Open questions There are still questions regarding the desired scope of the process. While 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 --=-=-=--