Re: Request-For-Comment process: concrete implementation
Hi Ricardo, On mer., 20 déc. 2023 at 12:49, Ricardo Wurmus wrote: > I just got back from travels and finally caught up with important email. > I read the proposal and it looks good to me. Thank you for working on > this! > > This would be the first project I contribute to that has an RFC process, > so I don’t know what to look out for. My concerns may thus be > completely out of touch with reality, so beware as you read on. Thank you for the feedback. Much appreciated! :-) I will address your question in another broad message. Cheers, simon
Re: Request-For-Comment process: concrete implementation
Hi Simon, > 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? I just got back from travels and finally caught up with important email. I read the proposal and it looks good to me. Thank you for working on this! This would be the first project I contribute to that has an RFC process, so I don’t know what to look out for. My concerns may thus be completely out of touch with reality, so beware as you read on. It seems to me that the exact process is a little vague, especially with regard to how long the comment period should be, and what expectations there are during this period. There is a chance that the open comment period will lead to derailing discussions of tangents that make it hard for the submitter to answer to real issues (because it would become increasingly difficult to read all messages). I’m thinking of some of the big discussions on the devel list in the past that became too big to follow, and resulted in “consensus by attrition”. Do you know how other projects avoid needlessly dragging on discussions about RFCs? Will *any* disagreement have to be addressed, or will there be an implicit weighing of opinions? As the project grows bigger there can be a problem of having inexperienced contributors (or those with qualifications that are irrelevant to the proposal) block the RFC without malicious intent by essentially requiring to be tutored on areas outside of their expertise. I wouldn’t trust myself to write an RFC without having played with an implementation first. I have doubts whether RFCs that are written without a proof of concept could reasonably be evaluated. Often details and subtle problems are discovered only when playing with a patch, and this may happen only after an RFC has been accepted. Can we take back approval in this RFC process? And lastly a typo: * “subtilities” should probably be “subtleties”. -- Ricardo
Re: Request-For-Comment process: concrete implementation
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
Re: Request-For-Comment process: concrete implementation
Hi Efraim, Thnaks for your comments. On Thu, 23 Nov 2023 at 09:04, Efraim Flashner wrote: > Actually, in terms of suggestions, I'd add the rfc/ folder in > etc/teams.scm to set guix-devel as one of the team members. Good idea! Cheers, simon
Re: Request-For-Comment process: concrete implementation
On Tue, Oct 31, 2023 at 12:14:42PM +0100, 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 I think this is a great idea and that we should implement it. Looking through it I didn't see anything that jumped out to me as something that needed to be changed. Currently we have largish changes split between guix-patches and guix-devel, with no real clear way to draw people's attention to them. Currently I'm aware of re-arranging the go packages, splitting some of the system services into their own modules, I'd like to add a field to (guix platform), it'd be good to formalize some of these processes to make it clearer about what's expected and what's going on. Actually, in terms of suggestions, I'd add the rfc/ folder in etc/teams.scm to set guix-devel as one of the team members. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Request-For-Comment process: concrete implementation
Simon Tournier skribis: > On Thu, 16 Nov 2023 at 16:03, Ludovic Courtès wrote: > >> Thanks for starting the discussion! I think that getting such a process >> in place is key to sustain friction-less development of Guix, giving >> everyone a chance to have their voice heard. > > Do you have comments on the current proposal? About points where you > think they could be improved? As wording? Or process? Or else? I haven’t taken the time to look at it yet but plan to do so. Thanks, Ludo’.
Re: Request-For-Comment process: concrete implementation
Hi Ludo, Thanks for giving a look. On Thu, 16 Nov 2023 at 16:03, Ludovic Courtès wrote: > Thanks for starting the discussion! I think that getting such a process > in place is key to sustain friction-less development of Guix, giving > everyone a chance to have their voice heard. Do you have comments on the current proposal? About points where you think they could be improved? As wording? Or process? Or else? Cheers, simon
Re: Request-For-Comment process: concrete implementation
Hello, Simon Tournier skribis: > This is a proposal for implementing Request-For-Comment process. > Comment are welcome in #66844 [1]: > > 1: https://issues.guix.gnu.org/issue/66844 Thanks for starting the discussion! I think that getting such a process in place is key to sustain friction-less development of Guix, giving everyone a chance to have their voice heard. Ludo’.
