From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id MF/NFlwpW2dJXgAA62LTzQ:P1 (envelope-from ) for ; Thu, 12 Dec 2024 18:20:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id MF/NFlwpW2dJXgAA62LTzQ (envelope-from ) for ; Thu, 12 Dec 2024 19:20:12 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=F0W+kmRh; dkim=fail ("headers rsa verify failed") header.d=gnu.org header.s=fencepost-gnu-org header.b=hnmMniRu; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734027612; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=XOgxHcln9PfstL14n6W/fjHXZCivNSP2hV3wWx8ASuI=; b=XnwpyL2fImEcmu33Nx857PO4zqUb7Jkgk3vqnGCMjEq6j+Q2rRMV1KrAFpYg5zVdLQvVX7 KRrUr6nCorsJc0eIGRLXxCvtwhfr2Qm8X4b6ibjpqzJYG0fgQLZBnwrmoKSZi+ab58oP6q CQOxyPHfKFvbtEFv+jN1A7y8Zo9VZzdDyIE3U1sJlNR0m2KF5SPz+YghUaEScsCP6Zw/74 4rvY+QJSYa14byaSqXEXKjS37EZXjYzDCon8SX/MKHVcTnY9KQdeSTfaakVlvSmUMilVtm gCUUampcD7QUM195VmCwoouiTk3VOArXgzUXMpBo9l8fm6J9PbQuC86j/lJofw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=F0W+kmRh; dkim=fail ("headers rsa verify failed") header.d=gnu.org header.s=fencepost-gnu-org header.b=hnmMniRu; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734027612; a=rsa-sha256; cv=none; b=ptEL2ghKhDzLfHVoZht8EFAGYS3XU1Wn2aEwJ+Oyj4ZqikhTGqx94XNq9JgBcePFEUga+c kblLoQE1DPdTL6RsJdvAE8ZGcQFEkppPh4lH7hWuGLoRZTSK/XlOlll9p5mvAceKzvGF1Y HmZGgiGaNuVKHK+jqUmVN9bVdLPfKmh6HaPZicPNFc/VNuqw/H5nbXEz+jOHslsa0mU9hg RYcpcY9WgceiWOYyvyzKSGV0NNCemUtb0RD1V35Mjrlkw9CtngGBoJwwaosbh8i6EvDr5P BVK3f45uvzQ7Y5A+GGIKC/AbZ7dUfjr1iuu8vLqX5pgXgHi0nN0CNcxhnOEgDA== 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 B29AF44F29 for ; Thu, 12 Dec 2024 19:20:11 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLnnA-0006Zr-GM; Thu, 12 Dec 2024 13:20:04 -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 1tLnn8-0006Yt-Pb for guix-patches@gnu.org; Thu, 12 Dec 2024 13:20:02 -0500 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tLnn8-0006HN-GZ for guix-patches@gnu.org; Thu, 12 Dec 2024 13:20:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=XOgxHcln9PfstL14n6W/fjHXZCivNSP2hV3wWx8ASuI=; b=F0W+kmRh1SA4wVXzOXS28WqTZoGxdBFpJaTQyUoB+A63VsQ3SM137RIc6ckXikCY52IQ7Yx6LEONH5dKduzLnpKzFWrQJPmHNVsoJoTjecmWOev+vdQEZ+JKkaBIdi3YtUsC9O18mMLEIthO299EuAg2cVmVXdDXX7crEB+9AStVodzqgBBHz32lA+eirOC9SCF1vhur/BOIFFIitYtKPtz/ApBPB23JCOOG98cIaI4kN6SUqNN/UCZOOgQbmdvLAIgG5LUQeWRyCzJLoxTVQUAK0sHA5+MMHXdDrFCHq1WBo7Ja+Bhu+oN8JWRBRE16xMXVolbPv2mNOftHdopuxA==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tLniI-0000Eh-Et for guix-patches@gnu.org; Thu, 12 Dec 2024 13:15:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 12 Dec 2024 18:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74736 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: =?UTF-8?Q?No=C3=A9?= Lopez Cc: 74736@debbugs.gnu.org, Christopher Baines , Simon Tournier Received: via spool by 74736-submit@debbugs.gnu.org id=B74736.1734027290855 (code B ref 74736); Thu, 12 Dec 2024 18:15:02 +0000 Received: (at 74736) by debbugs.gnu.org; 12 Dec 2024 18:14:50 +0000 Received: from localhost ([127.0.0.1]:40246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLni5-0000Dg-4n for submit@debbugs.gnu.org; Thu, 12 Dec 2024 13:14:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54066) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLni2-0000DD-66 for 74736@debbugs.gnu.org; Thu, 12 Dec 2024 13:14:47 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLnhv-0003zC-GD; Thu, 12 Dec 2024 13:14:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=XOgxHcln9PfstL14n6W/fjHXZCivNSP2hV3wWx8ASuI=; b=hnmMniRubgW7roevVKhE FkRz4uPpKMnbqjNTFa2AI8HNksH6r4pwrNxS3/HRo2RawbM4zQG/aOfNQtxWXxSF28bscmllZi4+9 HtH5e0lrGC1Xl3odzI6jaXWdW9ONBIm1lovellQCwaC6x0RFF9Tv7ThpOzGEw0hRfHQRJWQfKXH9d HjXjX34p89faXvm3nwHpRIuhdwAHoYnIRCr2La80LbPxMXqpq1WtV5s3N1RZkXXu12UYyBazp2z09 BX56Gk6Bz/Z0VQ0PBp/1u927zS4Gx8VXEST546BqDadIXMymsQCVW1gf11mroy0ovlWCN+9vABout 0Qm8Sr79vYTLyA==; From: Ludovic =?UTF-8?Q?Court=C3=A8s?= In-Reply-To: <09ff9f31af0575ba5223bf713f166101e79b8d99.1733614983.git.noelopez@free.fr> ("=?UTF-8?Q?No=C3=A9?= Lopez"'s message of "Sun, 8 Dec 2024 13:31:43 +0100") References: <09ff9f31af0575ba5223bf713f166101e79b8d99.1733614983.git.noelopez@free.fr> Date: Thu, 12 Dec 2024 19:14:31 +0100 Message-ID: <875xno7oqg.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -3.07 X-Spam-Score: -3.07 X-Migadu-Queue-Id: B29AF44F29 X-TUID: YQ4tmLM65UPC Hi No=C3=A9, Thanks a lot for resuming this work! That=E2=80=99s the right thing to do. Leaving out 000-rfc-template.txt for now. No=C3=A9 Lopez skribis: > +++ b/rfc/0001-rfc-process.txt > @@ -0,0 +1,232 @@ > +# -*- mode:org -*- > +#+TITLE: Request-For-Comment process > +#+DATE: 2023-10-31 [...] > +* Motivation > + > +The current way that we add new features to Guix has been good for early > +development, but it is starting to show its limits as Guix becomes a bro= adly > +used system with many contributors. Changes might be slowed down by the= lack > +of structure to acquire consensus. =E2=80=9C=E2=80=A6 to achieve consensus, lack of a central place to consult= contributors and users, and lack of clear deadlines.=E2=80=9D > +Note that this process does not cover most of the changes. It covers > +significant changes, for some examples: =E2=80=9CIt covers proposals significant changes, where =E2=80=9Csignifican= t=E2=80=9D means any change that could only be reverted at a high cost, or any change with the potential to disrupt user scripts and programs or user workflows. Examples include: =E2=80=9D > + + change of inputs style > + (Removing input labels from package definitions, #49169) > + + introduction of =3Dguix shell=3D and deprecation of =3Dguix environme= nt=3D > + (Add 'guix shell' to subsume 'guix environment', #50960) > + + introduction of authentication mechanism (Trustable "guix pull", #228= 83) > + + changes in policy (Add "Deprecation Policy", #72840) > + + collaboration via team and branch-features > + (several places mailing list guix-devel) These are changes from the past that may long be forgotten by the time we read them. Perhaps we can abstract it a bit, like: - changing the record type and/or its interfaces; - adding or removing a =E2=80=98guix=E2=80=99 sub-command; - changing the channel mechanism; - changing project policy such as teams, decision-making, the deprecation policy or this very document; - changing the contributor workflow and related infrastructure (mailing lists, source code repository and forge, continuous integration, etc.) This list seems redundant with and similar to that under =E2=80=9CWhen To F= ollow This Process=E2=80=9D; maybe just keep it in one place, under =E2=80=9CWhen= To Follow=E2=80=A6=E2=80=9D? > +* Detail design =E2=80=9CDetailed Design=E2=80=9D > +** When you need to follow this process =E2=80=9CWhen To Follow This Process=E2=80=9D > +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. > + > + + Changes that modify user-facing interfaces that may be relied on > + + Command-line interfaces > + + Core Scheme interfaces > + + Big restructuring of packages > + + Hard to revert changes > + + Governance and changes to the way we collaborate > + > +Certain changes do not require an RFC: > + > + - Adding, updating packages, removing outdated packages > + - Fixing security updates and bugs that don't break interfaces I would add =E2=80=9CGeneral day-to-day contributions follow the regular [decision-making process] and [team organization].=E2=80=9D, with reference= s to the relevant sections of the manual. > +A patch submission to Debbugs that contains any of the afore-mentioned Typo: =E2=80=9Caforementioned=E2=80=9D. I would remove =E2=80=9Cto Debbugs=E2=80=9D to keep it more general and fut= ure-proof. > +** How the process works > + > + 1. Clone https://git.savannah.gnu.org/git/guix.git I would suggest a separate repo. > + 2. Copy rfc/0000-template.org to rfc/00XY-good-name.org where good-nam= e is > + descriptive but not too long and XY increments > + 3. Fill RFC > + 4. Submit to guix-patches@gnu.org > + 5. Announce your RFC to guix-devel@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. Howeve= r, to > +improve the chance of a successful RFC, it might be recommended to have = an s/it might be/it is/ > +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 and other Guix communities are recommend= ed. =E2=80=9CPublicizing of the RFC on the project=E2=80=99s main communication= channels is mandatory.=E2=80=9D > +After a number of rounds of review, the discussion should settle and a g= eneral > +consensus should emerge. If the RFC is successful then authors may cont= ribute > +to the implementation. This bit is left intentionally vague and should = be > +refined in the future. I=E2=80=99d drop it or write =E2=80=9CSee the =E2=80=98Decision Process and= Timeline=E2=80=99 section below.=E2=80=9D > +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 al= l the > +major stakeholders have agreed to the feature and are amenable to mergin= g it. I=E2=80=99d write =E2=80=9Call the participants=E2=80=9D instead of =E2=80= =9Call the major stakeholders=E2=80=9D. > +The Guix projects ensures that a team of co-supporters =E2=80=93 the RFC= team =E2=80=93 remain > +available for any new RFCs that don=E2=80=99t find any co-supporters. T= his team > +should be added to the etc/teams.scm file. I would drop that. > +** Timeline > + > +The lifetime of an RFC is structured into the following periods: > + submission (7d) =E2=9F=B6 comments (30=E2=80=9360d) =E2=9F=B6 last cal= l (14d) =E2=9F=B6 withdrawn OR final Let=E2=80=99s borrow from the state transition diagram from at , for clarity. Perhaps we should also shorten the text of each section below. In each section heading, I would add its duration: *** Submission (up to 7 days) =E2=80=A6 *** Discussion (at least 30 days, up to 60 days) =E2=80=A6 > +*** Comment > + > +The author publishes their RFC to guix-devel and starts a discussion per= iod of =E2=80=9CThe author publicizes their RFC, marking the start of a discussion period of at least 30 days and at most 60 days.=E2=80=9D > +*** Last call > + > +The author publishes a final version of the RFC and a 14 day period is g= iven > +for people to express their agreement or disagreement. If a positive > +consensus is reached the RFC becomes final and the changes should be app= lied =E2=80=9CIf consensus is reached, the RFC becomes =E2=80=A6=E2=80=9D > +in less than six months. I=E2=80=99m not sure what =E2=80=9Cthe changes=E2=80=9D refers to. Regarding consensus, I would add a link to the =E2=80=9CMaking Decisions=E2= =80=9D section of the manual=E2=80=A6 > +** Decision making: consensus =E2=80=A6 and drop this. > +** Merging the outcome > + > +Once a consesus is made, a committer should do the following to merge th= e RFC: > + > + 1. Fill in the remaining metadata in the RFC header, including links fo= r the > + original Debbugs submission. > + 2. Commit everything. > + 3. Announce the establishment of the RFC to all the stakeholders. > + 4. Ensure the RFC is applied within six months. Maybe we should define the role of =E2=80=9CRFC editors=E2=80=9D (or =E2=80= =9CRFC team=E2=80=9D?), which would be the people responsible for doing those changes. > +** Template of RFC > + > +# Ludovic Court=C3=A8s: > +# I=E2=80=99d go for one format, preferably Markdown because we have a l= ibrary to > +# parse it. Yes! :-) Despite being an Org fan, I think we should stick to Markdown: it=E2=80=99s widespread, well-known, and can be rendered by Haunt or by any forge. > +** Backward Compatibility > + > +None. > + > +** Forward compatibility I=E2=80=99m not sure what=E2=80=99s expected in these sections. Maybe =E2= =80=9CCompatibility Considerations=E2=80=9D would be more appropriate? > +** Drawbacks > + > +There is a risk that the additional process will hinder contribution mor= e than > +it would help. We should stay alert that the process is only a way to h= elp > +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 r= atio > +in collected feedback, particularly on easily bike-shedded topics. > + > +** Open questions > + > +There are still questions regarding the desired scope of the process. W= hile > +we want to ensure that changes which affect the users are well-considere= d, 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 I think these two sections in the context of this foundational document look a bit ridiculous. :-) But maybe that=E2=80=99s okay? Thanks! Ludo=E2=80=99.