Hi,
Well, more than 7 weeks later… Hum, does it mean that the Guix project
is not interested in formalizing some RFC?
WDYT about the proposal?
On Tue, 31 Oct 2023 at 12:14, Simon Tournier wrote:
> 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
> ===
>
> # -*- 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 early
> 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. 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 consistently
> 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 =guix shell= and deprecation of =guix environment=
>(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/-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-patc...@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 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 general
> consensus should emerge. If the RFC is successful then authors may contribute
> to the implementation. This bit is left
