GNU logs - #66844, boring messages

Message sent to guix-patches@HIDDEN:

Subject: [bug#66844] [PATCH 0/1] Add Request-For-Comment process.
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 31 Oct 2023 11:07:02 +0000
Resent-Message-ID: <handler.66844.B.169875037623888 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 66844 <at> debbugs.gnu.org
Cc: Simon Tournier <zimon.toutoune@HIDDEN>
From: Simon Tournier <zimon.toutoune@HIDDEN>
Date: Tue, 31 Oct 2023 12:05:22 +0100
Message-ID: <cover.1698747252.git.zimon.toutoune@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=2a00:1450:4864:20::42f;
 envelope-from=zimon.toutoune@HIDDEN; helo=mail-wr1-x42f.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 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hi,

This is a proposal for implementing Request-For-Comment process.  It 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.

The aim is to remove “Why wasn't I consulted” situations for “substantial”
changes by improving the current process.  Somehow, this patch is an attempt
to make concrete what had been expressed several times; for one instance:

        Time for a request-for-comments process?
        Ludovic Courtès <ludo@HIDDEN>
        Wed, 27 Oct 2021 23:22:50 +0200
        id:87cznqb1sl.fsf@HIDDEN
        https://lists.gnu.org/archive/html/guix-devel/2021-10
        https://yhetil.org/guix/87cznqb1sl.fsf@HIDDEN

Again, please note that this process is about “substantial” changes that are
very few.

WDYT?

Cheers,
simon

1: https://github.com/ghc-proposals/ghc-proposals
2: https://github.com/NixOS/rfcs

Simon Tournier (1):
  rfc: Add Request-For-Comment process.

 rfc/0000-template.txt    |  58 +++++++++++++
 rfc/0001-rfc-process.txt | 180 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 238 insertions(+)
 create mode 100644 rfc/0000-template.txt
 create mode 100644 rfc/0001-rfc-process.txt

base-commit: c0895371c5759c7d9edb330774e90f192cc4cf2c
-- 
2.41.0

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Simon Tournier <zimon.toutoune@HIDDEN>
Subject: bug#66844: Acknowledgement ([PATCH 0/1] Add Request-For-Comment
 process.)
Message-ID: <handler.66844.B.169875037623888.ack <at> debbugs.gnu.org>
References: <cover.1698747252.git.zimon.toutoune@HIDDEN>
X-Gnu-PR-Message: ack 66844
X-Gnu-PR-Package: guix-patches
X-Gnu-PR-Keywords: patch
Reply-To: 66844 <at> debbugs.gnu.org
Date: Tue, 31 Oct 2023 11:07:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 guix-patches@HIDDEN

If you wish to submit further information on this problem, please
send it to 66844 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
66844: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66844
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to guix-patches@HIDDEN:

Subject: [bug#66844] [PATCH] rfc: Add Request-For-Comment process.
References: <cover.1698747252.git.zimon.toutoune@HIDDEN>
In-Reply-To: <cover.1698747252.git.zimon.toutoune@HIDDEN>
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 31 Oct 2023 11:09:02 +0000
Resent-Message-ID: <handler.66844.B66844.169875053624149 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 66844 <at> debbugs.gnu.org
Cc: Simon Tournier <zimon.toutoune@HIDDEN>
From: Simon Tournier <zimon.toutoune@HIDDEN>
Date: Tue, 31 Oct 2023 12:08:04 +0100
Message-ID: <dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

* rfc/0001-rfc-process.txt: New file.
* rfc/0000-template.txt: New file.

Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208
---
 rfc/0000-template.txt    |  58 +++++++++++++
 rfc/0001-rfc-process.txt | 180 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 238 insertions(+)
 create mode 100644 rfc/0000-template.txt
 create mode 100644 rfc/0001-rfc-process.txt

diff --git a/rfc/0000-template.txt b/rfc/0000-template.txt
new file mode 100644
index 0000000000..22dca35a56
--- /dev/null
+++ b/rfc/0000-template.txt
@@ -0,0 +1,58 @@
+# -*- mode:org -*-
+#+TITLE: <The meaningful name of the proposal>
+#+DATE: <date when the process starts>
+
++ Issue: <number assigned by Debbugs>
++ Status: <pending|done|unsuccessful|deprecated>
++ Supporter: <Your Name>
++ Co-supporter(s): <Some> <Names>
+
+* Summary
+
+A one-paragraph explanation.  Main sales pitch.
+
+* Motivation
+
+Describe the use case as clearly as possible and optionally give an example.
+Explain how the status quo is insufficient or not ideal.  This section answers
+Why is this proposal a good idea?  Why is it worth the effort to discuss and
+implement such?
+
+* Detail design
+
+Main part.  The sections answers What is the cost of this proposal compared to
+status quo or potential alternatives?  Explain details, corner cases, provide
+examples.  Explain it so that someone familiar can understand.
+
+It is best to exemplify, contrived example too. If the Motivation section
+describes something that is hard to do without this proposal, this is a good
+place to show how easy that thing is to do with the proposal.
+
+**  Backward Compatibility
+
+Will your proposed change cause a behaviour change?  Assess the expected
+impact on existing code on the following scale:
+
+0. No breakage
+1. Breakage only in extremely rare cases (exotic or unknown cases)
+2. Breakage in rare cases (user living in cutting-edge)
+3. Breakage in common cases
+
+Explain why the benefits of the change outweigh the costs of breakage.
+Describe the migration path.  Consider specifying a compatibility warning for
+one or more releases.  Give examples of error that will be reported for
+previously-working cases; do they make it easy for users to understand what
+needs to change and why?
+
+The aim is to explicitely consider beforehand potential Backward Compatibility
+issue.
+
+* Unresolved questions
+
+Explicitly list any remaining issues.  At submitting time, be upfront and
+trust that the community will help.  At reviewing time, this section tracks
+the details about the status of the process.
+
+At the end of the process, this section will be empty.  If not, please be
+explicit with the known issues by adding a dedicated subsection under Detail
+design.
diff --git a/rfc/0001-rfc-process.txt b/rfc/0001-rfc-process.txt
new file mode 100644
index 0000000000..8424303949
--- /dev/null
+++ b/rfc/0001-rfc-process.txt
@@ -0,0 +1,180 @@
+# -*- 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/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@HIDDEN
+
+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 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 refusal
+should rather be interpreted as “let’s discuss again with a different angle”.
+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’s
+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 the
+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 with.
+
+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 bears
+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
+<https://www.seedsforchange.org.uk/consensus>.
+
+** 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 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

base-commit: c0895371c5759c7d9edb330774e90f192cc4cf2c
-- 
2.41.0

Message sent to guix-patches@HIDDEN:

Subject: [bug#66844] [PATCH] rfc: Add Request-For-Comment process.
Resent-From: Christopher Baines <mail@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 05 Feb 2024 10:44:02 +0000
Resent-Message-ID: <handler.66844.B.170712979810427 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: 66844 <at> debbugs.gnu.org
References: <cover.1698747252.git.zimon.toutoune@HIDDEN>
 <dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@HIDDEN>
User-agent: mu4e 1.10.7; emacs 29.1
From: Christopher Baines <mail@HIDDEN>
Date: Sun, 04 Feb 2024 17:30:24 +0100
In-reply-to: <dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@HIDDEN>
Message-ID: <87il33dwf1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Received-SPF: pass client-ip=2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27;
 envelope-from=mail@HIDDEN; helo=mira.cbaines.net
X-Spam_score_int: -8
X-Spam_score: -0.9
X-Spam_bar: /
X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.7 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Simon Tournier <zimon.toutoune@HIDDEN> writes: > *
 rfc/0001-rfc-process.txt:
 New file. > * rfc/0000-template.txt: New file. > > Change-Id:
 Ide88e70dc785ab954ccb42fb043625db12191208
 > --- > rfc/0000-template.txt | 58 +++++++++++++ > rfc/0001-rfc-pr [...] 
 Content analysis details:   (1.7 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=mail%40cbaines.net; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.8 DATE_IN_PAST_12_24     Date: is 12 to 24 hours before Received: date
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Simon Tournier <zimon.toutoune@HIDDEN> writes:

> * rfc/0001-rfc-process.txt: New file.
> * rfc/0000-template.txt: New file.
>
> Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208
> ---
>  rfc/0000-template.txt    |  58 +++++++++++++
>  rfc/0001-rfc-process.txt | 180 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 238 insertions(+)
>  create mode 100644 rfc/0000-template.txt
>  create mode 100644 rfc/0001-rfc-process.txt
>
> diff --git a/rfc/0000-template.txt b/rfc/0000-template.txt
> new file mode 100644
> index 0000000000..22dca35a56
> --- /dev/null
> +++ b/rfc/0000-template.txt
> @@ -0,0 +1,58 @@
> +# -*- mode:org -*-
> +#+TITLE: <The meaningful name of the proposal>
> +#+DATE: <date when the process starts>
> +
> ++ Issue: <number assigned by Debbugs>
> ++ Status: <pending|done|unsuccessful|deprecated>
> ++ Supporter: <Your Name>
> ++ Co-supporter(s): <Some> <Names>
> +

Thanks for writing this up Simon.

Some bikeshedding over the specific words and phrases follows, but I've
also got a few actual changes to suggest.

Generally I think this is something to try, I think the key issues to
address are around what is suitable for an RFC, and including some
checkpoints in the structure to encourage the discussion along and
identify when it's no longer progressing.

> +* Summary
> +
> +A one-paragraph explanation.  Main sales pitch.

I'm not sure a summary is needed, or maybe it should just be a single
sentence summary. I think the Motivation section may end up just
repeating most of this and is a more useful thing to read first.

> +* Motivation
> +
> +Describe the use case as clearly as possible and optionally give an exam=
ple.
> +Explain how the status quo is insufficient or not ideal.  This section a=
nswers
> +Why is this proposal a good idea?  Why is it worth the effort to discuss=
 and
> +implement such?

I'd maybe say "Describe the problem(s) this RFC attempts to address, and
how it might do this". I'm also not sure we need the last sentence,
although maybe it would be good to have a paragraph specifically on what
makes this suitable for an RFC.

> +* Detail design
> +
> +Main part.  The sections answers What is the cost of this proposal compa=
red to
> +status quo or potential alternatives?  Explain details, corner cases, pr=
ovide
> +examples.  Explain it so that someone familiar can understand.

Maybe tradeoffs would be a better word to use rather than cost, so "What
are the tradeoffs of this proposal compared ...".

> +It is best to exemplify, contrived example too. If the Motivation section
> +describes something that is hard to do without this proposal, this is a =
good
> +place to show how easy that thing is to do with the proposal.
> +
> +**  Backward Compatibility
> +
> +Will your proposed change cause a behaviour change?  Assess the expected
> +impact on existing code on the following scale:
> +
> +0. No breakage
> +1. Breakage only in extremely rare cases (exotic or unknown cases)
> +2. Breakage in rare cases (user living in cutting-edge)
> +3. Breakage in common cases
> +
> +Explain why the benefits of the change outweigh the costs of breakage.
> +Describe the migration path.  Consider specifying a compatibility warnin=
g for
> +one or more releases.  Give examples of error that will be reported for
> +previously-working cases; do they make it easy for users to understand w=
hat
> +needs to change and why?
> +
> +The aim is to explicitely consider beforehand potential Backward Compati=
bility
> +issue.

I'm struggling to think of exactly how backwards compatibility would
apply to potential RFCs for Guix.

I do think it's worth explicitly bringing up something like the "cost of
reverting". That is, it's important to discuss things more if there's a
high cost to changing the approach later. For these "high cost of later
change" situations, the RFC process will probably be particularly
valuable.

> +* Unresolved questions
> +
> +Explicitly list any remaining issues.  At submitting time, be upfront and
> +trust that the community will help.  At reviewing time, this section tra=
cks
> +the details about the status of the process.
> +
> +At the end of the process, this section will be empty.  If not, please be
> +explicit with the known issues by adding a dedicated subsection under De=
tail
> +design.
> diff --git a/rfc/0001-rfc-process.txt b/rfc/0001-rfc-process.txt
> new file mode 100644
> index 0000000000..8424303949
> --- /dev/null
> +++ b/rfc/0001-rfc-process.txt
> @@ -0,0 +1,180 @@
> +# -*- 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 consis=
tent
> +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.

Maybe "structured" rather than "controlled".

I also think this should be more general than new features. To me this
is about making decisions collectively.

For example, an RFC might be about controlling scope or doing some key
refactoring rather than adding new features.

> +* 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 dev=
elop
> +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 integr=
al
> +part of the overall development process, and one that is followed consis=
tently
> +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 en=
ough
> +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)

I think this is a good example, again, I think we shouldn't just limit
RFCs for new features and this is an example of something that isn't a
new feature.

I think the RFC process would have been useful because there's a high
cost in doing this refactoring and in undoing it if something goes
wrong.

> + + introduction of =3Dguix shell=3D and deprecation of =3Dguix environme=
nt=3D
> +   (Add 'guix shell' to subsume 'guix environment', #50960)

Maybe an RFC could be useful here since removing or changing the shell
command after it's added would be difficult.

> + + introduction of authentication mechanism (Trustable "guix pull", #228=
83)

This does seem suitable of an RFC because of the complexity of fixing
issues after it's introduced.

> + + massive Python 2 removal
> +   (Merging the purge-python2-packages branch, mailing list guix-devel)

Adding Python 2 back doesn't seem difficult, so I'm not sure this would
benefit from being discussed as a specific RFC.

Maybe you could have an RFC about the policy for keeping software around
in Guix, and then the structured RFC process would help the discussion,
but I don't think it's useful for specific issues like this.

> + + collaboration via team and branch-features
> +   (several places mailing list guix-devel)

Like above, because this is a discussion about process, I think the RFC
process could provide structure, and authority to the decision made.

I think generally I think the RFC process is useful when the decisions
are hard/costly to revert and/or for cases where the discussion benefits
from the structure and authority that the RFC process can provide.

> +* 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

The key thing in my mind is changes that are hard to revert. Some API
changes may be hard to revert, but some could be very minor (e.g. making
a existing procedure public).

> +  + Big restructuring of packages
> +  + Introduction or removal of subcommands

I guess this would normally mean a hard to revert change.

> +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-nam=
e is
> +     descriptive but not too long and XY increments
> +  3. Fill RFC
> +  4. Submit to guix-patches@HIDDEN
> +
> +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
> +idea for implementing it.  If an implementation is attached to the detai=
led
> +design, it might help the discussion.
> +
> +At this point, at least one other person must volunteer to be "co-suppor=
ter".
> +The aim is to improve the chances that the RFC is both desired and likel=
y 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.

Having made a few changes to Guix's API over the years (e.g. adding
narinfo stuff to the API #45409) I think we maybe need to provide a
backstop for requiring supporters.

There's plenty of useful but boring API changes that have happened, and
probably will happen in the future, and we maybe need to set out that
there's some group of people (maybe committers) which will be
co-supporters if there's not anyone volunteering.

> +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 think we should specify a time period (say 3 weeks) where the proposer
needs to send out an update saying what the state is, and there should
be a requirement that the discussion has progressed since the previous
update. If the discussion is no longer progressing, it's time to
reject/accept/pause or do something else with the RFC.

> +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.
> +
> +An unsuccessful RFC is *not* a judgment on the value of the work, so a r=
efusal
> +should rather be interpreted as =E2=80=9Clet=E2=80=99s discuss again wit=
h 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 contribut=
or
> +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 timekee=
per
> +and helps in pushing forward until process completion.
> +
> +The co-supporter doesn't necessarily have to agree with all the points o=
f the
> +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 les=
s.
> +
> +** 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 =
with.
> +
> +It implies that no decision is made against significant concerns and the=
se
> +concerns are actively resolved with proposals that work for everyone.  A
> +contributor, without or with commit access, wishing to block a proposal =
bears
> +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
> +<https://www.seedsforchange.org.uk/consensus>.
> +
> +** Merging the outcome
> +
> +Whoever merges the successful RFC should do the following:
> +
> + 1. Fill in the remaining metadata in the RFC header, including links fo=
r the
> +    original Debbugs submission.
> + 2. Commit everything.

We should explicitly place the burden here on committers to avoid
ambiguity. e.g. for RFCs that are approved, a committer will merge it in
to the repository.

> +** 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 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
>
> base-commit: c0895371c5759c7d9edb330774e90f192cc4cf2c


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmXAu6JfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdnbQ/9HrhTKaFJD4KD92hisJiYb1I4K9U/3VvD
Jco/St+cumCX8zgR0vjGDr4ciuasnCTno6c+0Iv0460JUhXaTTadq5fG9Dugmir+
YPQe5aBVtDQV5LrwonJbk/xvvJeYEFU4pFZoC9nxiJ4UdQaRJmT7+0b7XxeEo97c
6CeFFejS3GMT3YTc8mz/4uWiOYvuaXJjSFGFzG68hOUYojj2YEGUfFSYtTZ60r5Q
vG37eSvy9eYo7P7afCMn06TR39VsEb8E51biBI9Rh2boUS4c0P4FH6xUMSpg1Qn7
ax9C8v601FKOiHsX82Od5jN1VrStAaFuU7tBK57GO9K2flUd4GLYYED46wrYbOSk
bvpFZDNyNcOrUyhus7mCryV1KxzlH+XA80nJNBsQD2+kM4orLugDOwjTpQ8E7JZc
/PmOxZstDbjrotja492eq2tAGRLMvLZUwYR/Npo1Tra4ubYSB1okyVnE9AVpqTFq
JxqCvb+7C1DB4M24GvaDvZWSf0zZQVPd/sSxFQcNIO6gvJvPwqCBUlV+HZFkqmHt
vCrqXrfIL/DMoKk5rgfgKv3jJ7ENrA9/9xWCpWnmNLm/m1sG8ZnKo29JD4MHSl4z
iYqbiTRJ7COKm6S5lFF3PKT3bmYtccTTVwuGbkTs+ak5bHxMeRqHHukFyrxjkUrn
4uBl97dATmQ=
=vRSL
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#66844] [PATCH] rfc: Add Request-For-Comment process.
Resent-From: Christopher Baines <mail@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 05 Feb 2024 10:44:02 +0000
Resent-Message-ID: <handler.66844.B66844.170712978410398 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66844
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: 66844 <at> debbugs.gnu.org
X-Debbugs-Original-Cc: 66844 <at> debbugs.gnu.org, guix-patches@HIDDEN
Received: via spool by 66844-submit <at> debbugs.gnu.org id=B66844.170712978410398
          (code B ref 66844); Mon, 05 Feb 2024 10:44:02 +0000
Received: (at 66844) by debbugs.gnu.org; 5 Feb 2024 10:43:04 +0000
Received: from localhost ([127.0.0.1]:50634 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rWwRL-0002hd-9A
	for submit <at> debbugs.gnu.org; Mon, 05 Feb 2024 05:43:04 -0500
Received: from mira.cbaines.net ([212.71.252.8]:43100)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mail@HIDDEN>) id 1rWwRH-0002hD-R1
 for 66844 <at> debbugs.gnu.org; Mon, 05 Feb 2024 05:43:01 -0500
Received: from localhost (unknown [31.31.156.16])
 by mira.cbaines.net (Postfix) with ESMTPSA id 2FBF227BBE9;
 Mon,  5 Feb 2024 10:42:46 +0000 (GMT)
Received: from felis (localhost [127.0.0.1])
 by localhost (OpenSMTPD) with ESMTP id 756c301c;
 Mon, 5 Feb 2024 10:42:45 +0000 (UTC)
References: <cover.1698747252.git.zimon.toutoune@HIDDEN>
 <dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@HIDDEN>
User-agent: mu4e 1.10.7; emacs 29.1
From: Christopher Baines <mail@HIDDEN>
Date: Sun, 04 Feb 2024 17:30:24 +0100
In-reply-to: <dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@HIDDEN>
Message-ID: <87il33dwf1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.8 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Simon Tournier <zimon.toutoune@HIDDEN> writes:

> * rfc/0001-rfc-process.txt: New file.
> * rfc/0000-template.txt: New file.
>
> Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208
> ---
>  rfc/0000-template.txt    |  58 +++++++++++++
>  rfc/0001-rfc-process.txt | 180 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 238 insertions(+)
>  create mode 100644 rfc/0000-template.txt
>  create mode 100644 rfc/0001-rfc-process.txt
>
> diff --git a/rfc/0000-template.txt b/rfc/0000-template.txt
> new file mode 100644
> index 0000000000..22dca35a56
> --- /dev/null
> +++ b/rfc/0000-template.txt
> @@ -0,0 +1,58 @@
> +# -*- mode:org -*-
> +#+TITLE: <The meaningful name of the proposal>
> +#+DATE: <date when the process starts>
> +
> ++ Issue: <number assigned by Debbugs>
> ++ Status: <pending|done|unsuccessful|deprecated>
> ++ Supporter: <Your Name>
> ++ Co-supporter(s): <Some> <Names>
> +

Thanks for writing this up Simon.

Some bikeshedding over the specific words and phrases follows, but I've
also got a few actual changes to suggest.

Generally I think this is something to try, I think the key issues to
address are around what is suitable for an RFC, and including some
checkpoints in the structure to encourage the discussion along and
identify when it's no longer progressing.

> +* Summary
> +
> +A one-paragraph explanation.  Main sales pitch.

I'm not sure a summary is needed, or maybe it should just be a single
sentence summary. I think the Motivation section may end up just
repeating most of this and is a more useful thing to read first.

> +* Motivation
> +
> +Describe the use case as clearly as possible and optionally give an exam=
ple.
> +Explain how the status quo is insufficient or not ideal.  This section a=
nswers
> +Why is this proposal a good idea?  Why is it worth the effort to discuss=
 and
> +implement such?

I'd maybe say "Describe the problem(s) this RFC attempts to address, and
how it might do this". I'm also not sure we need the last sentence,
although maybe it would be good to have a paragraph specifically on what
makes this suitable for an RFC.

> +* Detail design
> +
> +Main part.  The sections answers What is the cost of this proposal compa=
red to
> +status quo or potential alternatives?  Explain details, corner cases, pr=
ovide
> +examples.  Explain it so that someone familiar can understand.

Maybe tradeoffs would be a better word to use rather than cost, so "What
are the tradeoffs of this proposal compared ...".

> +It is best to exemplify, contrived example too. If the Motivation section
> +describes something that is hard to do without this proposal, this is a =
good
> +place to show how easy that thing is to do with the proposal.
> +
> +**  Backward Compatibility
> +
> +Will your proposed change cause a behaviour change?  Assess the expected
> +impact on existing code on the following scale:
> +
> +0. No breakage
> +1. Breakage only in extremely rare cases (exotic or unknown cases)
> +2. Breakage in rare cases (user living in cutting-edge)
> +3. Breakage in common cases
> +
> +Explain why the benefits of the change outweigh the costs of breakage.
> +Describe the migration path.  Consider specifying a compatibility warnin=
g for
> +one or more releases.  Give examples of error that will be reported for
> +previously-working cases; do they make it easy for users to understand w=
hat
> +needs to change and why?
> +
> +The aim is to explicitely consider beforehand potential Backward Compati=
bility
> +issue.

I'm struggling to think of exactly how backwards compatibility would
apply to potential RFCs for Guix.

I do think it's worth explicitly bringing up something like the "cost of
reverting". That is, it's important to discuss things more if there's a
high cost to changing the approach later. For these "high cost of later
change" situations, the RFC process will probably be particularly
valuable.

> +* Unresolved questions
> +
> +Explicitly list any remaining issues.  At submitting time, be upfront and
> +trust that the community will help.  At reviewing time, this section tra=
cks
> +the details about the status of the process.
> +
> +At the end of the process, this section will be empty.  If not, please be
> +explicit with the known issues by adding a dedicated subsection under De=
tail
> +design.
> diff --git a/rfc/0001-rfc-process.txt b/rfc/0001-rfc-process.txt
> new file mode 100644
> index 0000000000..8424303949
> --- /dev/null
> +++ b/rfc/0001-rfc-process.txt
> @@ -0,0 +1,180 @@
> +# -*- 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 consis=
tent
> +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.

Maybe "structured" rather than "controlled".

I also think this should be more general than new features. To me this
is about making decisions collectively.

For example, an RFC might be about controlling scope or doing some key
refactoring rather than adding new features.

> +* 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 dev=
elop
> +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 integr=
al
> +part of the overall development process, and one that is followed consis=
tently
> +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 en=
ough
> +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)

I think this is a good example, again, I think we shouldn't just limit
RFCs for new features and this is an example of something that isn't a
new feature.

I think the RFC process would have been useful because there's a high
cost in doing this refactoring and in undoing it if something goes
wrong.

> + + introduction of =3Dguix shell=3D and deprecation of =3Dguix environme=
nt=3D
> +   (Add 'guix shell' to subsume 'guix environment', #50960)

Maybe an RFC could be useful here since removing or changing the shell
command after it's added would be difficult.

> + + introduction of authentication mechanism (Trustable "guix pull", #228=
83)

This does seem suitable of an RFC because of the complexity of fixing
issues after it's introduced.

> + + massive Python 2 removal
> +   (Merging the purge-python2-packages branch, mailing list guix-devel)

Adding Python 2 back doesn't seem difficult, so I'm not sure this would
benefit from being discussed as a specific RFC.

Maybe you could have an RFC about the policy for keeping software around
in Guix, and then the structured RFC process would help the discussion,
but I don't think it's useful for specific issues like this.

> + + collaboration via team and branch-features
> +   (several places mailing list guix-devel)

Like above, because this is a discussion about process, I think the RFC
process could provide structure, and authority to the decision made.

I think generally I think the RFC process is useful when the decisions
are hard/costly to revert and/or for cases where the discussion benefits
from the structure and authority that the RFC process can provide.

> +* 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

The key thing in my mind is changes that are hard to revert. Some API
changes may be hard to revert, but some could be very minor (e.g. making
a existing procedure public).

> +  + Big restructuring of packages
> +  + Introduction or removal of subcommands

I guess this would normally mean a hard to revert change.

> +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-nam=
e is
> +     descriptive but not too long and XY increments
> +  3. Fill RFC
> +  4. Submit to guix-patches@HIDDEN
> +
> +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
> +idea for implementing it.  If an implementation is attached to the detai=
led
> +design, it might help the discussion.
> +
> +At this point, at least one other person must volunteer to be "co-suppor=
ter".
> +The aim is to improve the chances that the RFC is both desired and likel=
y 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.

Having made a few changes to Guix's API over the years (e.g. adding
narinfo stuff to the API #45409) I think we maybe need to provide a
backstop for requiring supporters.

There's plenty of useful but boring API changes that have happened, and
probably will happen in the future, and we maybe need to set out that
there's some group of people (maybe committers) which will be
co-supporters if there's not anyone volunteering.

> +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 think we should specify a time period (say 3 weeks) where the proposer
needs to send out an update saying what the state is, and there should
be a requirement that the discussion has progressed since the previous
update. If the discussion is no longer progressing, it's time to
reject/accept/pause or do something else with the RFC.

> +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.
> +
> +An unsuccessful RFC is *not* a judgment on the value of the work, so a r=
efusal
> +should rather be interpreted as =E2=80=9Clet=E2=80=99s discuss again wit=
h 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 contribut=
or
> +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 timekee=
per
> +and helps in pushing forward until process completion.
> +
> +The co-supporter doesn't necessarily have to agree with all the points o=
f the
> +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 les=
s.
> +
> +** 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 =
with.
> +
> +It implies that no decision is made against significant concerns and the=
se
> +concerns are actively resolved with proposals that work for everyone.  A
> +contributor, without or with commit access, wishing to block a proposal =
bears
> +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
> +<https://www.seedsforchange.org.uk/consensus>.
> +
> +** Merging the outcome
> +
> +Whoever merges the successful RFC should do the following:
> +
> + 1. Fill in the remaining metadata in the RFC header, including links fo=
r the
> +    original Debbugs submission.
> + 2. Commit everything.

We should explicitly place the burden here on committers to avoid
ambiguity. e.g. for RFCs that are approved, a committer will merge it in
to the repository.

> +** 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 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
>
> base-commit: c0895371c5759c7d9edb330774e90f192cc4cf2c


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmXAu6JfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdnbQ/9HrhTKaFJD4KD92hisJiYb1I4K9U/3VvD
Jco/St+cumCX8zgR0vjGDr4ciuasnCTno6c+0Iv0460JUhXaTTadq5fG9Dugmir+
YPQe5aBVtDQV5LrwonJbk/xvvJeYEFU4pFZoC9nxiJ4UdQaRJmT7+0b7XxeEo97c
6CeFFejS3GMT3YTc8mz/4uWiOYvuaXJjSFGFzG68hOUYojj2YEGUfFSYtTZ60r5Q
vG37eSvy9eYo7P7afCMn06TR39VsEb8E51biBI9Rh2boUS4c0P4FH6xUMSpg1Qn7
ax9C8v601FKOiHsX82Od5jN1VrStAaFuU7tBK57GO9K2flUd4GLYYED46wrYbOSk
bvpFZDNyNcOrUyhus7mCryV1KxzlH+XA80nJNBsQD2+kM4orLugDOwjTpQ8E7JZc
/PmOxZstDbjrotja492eq2tAGRLMvLZUwYR/Npo1Tra4ubYSB1okyVnE9AVpqTFq
JxqCvb+7C1DB4M24GvaDvZWSf0zZQVPd/sSxFQcNIO6gvJvPwqCBUlV+HZFkqmHt
vCrqXrfIL/DMoKk5rgfgKv3jJ7ENrA9/9xWCpWnmNLm/m1sG8ZnKo29JD4MHSl4z
iYqbiTRJ7COKm6S5lFF3PKT3bmYtccTTVwuGbkTs+ak5bHxMeRqHHukFyrxjkUrn
4uBl97dATmQ=
=vRSL
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#66844] [PATCH] rfc: Add Request-For-Comment process.
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 05 Feb 2024 14:30:03 +0000
Resent-Message-ID: <handler.66844.B66844.170714337113249 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66844
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: 66844 <at> debbugs.gnu.org
Received: via spool by 66844-submit <at> debbugs.gnu.org id=B66844.170714337113249
          (code B ref 66844); Mon, 05 Feb 2024 14:30:03 +0000
Received: (at 66844) by debbugs.gnu.org; 5 Feb 2024 14:29:31 +0000
Received: from localhost ([127.0.0.1]:50843 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rWzyT-0003Rb-IE
	for submit <at> debbugs.gnu.org; Mon, 05 Feb 2024 09:29:31 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37860)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1rWzyO-0003RL-AK
 for 66844 <at> debbugs.gnu.org; Mon, 05 Feb 2024 09:29:28 -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 <ludo@HIDDEN>)
 id 1rWzy5-000787-Qe; Mon, 05 Feb 2024 09:29:06 -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=p+N6KgHy7U/KGuQFl4Jxq8EB3btoeHEFttZIKcTkb6E=; b=kFyhVaR09z2dGd5eyoBp
 dLALV4zhVTGjVNs7MMlFNnDORxlYfOSP6uVS3lINLJF4mHMAoHjCSflqxuygAfwxQlQ2aw54sFgAF
 VnsU5uAF1L9kDxmqYlbrBVxCF39TxlyKYFNJz1c9qSfxvXcts7nX0GdMYYHSdYTLnoh3lbme++rQx
 VZK+wjuvHnnodjqgY7+EA/pxUEyJh5mY274+8z2RsDwZXqafXu/ZDia7K900QUc54b/UrrZy0CJbw
 EDM2zK3WMLdOolT+mmqI/+dQikbNfx0dxlKBDCDQtqNF5CC5H29CvSBf6CUpa1nmvAJ1kKrnS8KPj
 MC9uBzZBAoxQCg==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@HIDDEN>
 (Simon Tournier's message of "Tue, 31 Oct 2023 12:08:04 +0100")
References: <cover.1698747252.git.zimon.toutoune@HIDDEN>
 <dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@HIDDEN>
Date: Mon, 05 Feb 2024 15:28:54 +0100
Message-ID: <87mssfast5.fsf@HIDDEN>
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-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hello!

Simon Tournier <zimon.toutoune@HIDDEN> skribis:

> --- /dev/null
> +++ b/rfc/0001-rfc-process.txt
> @@ -0,0 +1,180 @@
> +# -*- 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 consis=
tent
> +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 dev=
elop
> +some more self-discipline when it comes to changing our beloved system. =
 This

I agree with the spirit but I=E2=80=99m happy to propose wording changes on=
ce
there=E2=80=99s consensus on the general direction (for example, I think
=E2=80=9Cfreewheeling=E2=80=9D, =E2=80=9Cbeloved=E2=80=9D, and =E2=80=9Csel=
f-discipline=E2=80=9D are too casual and/or
demeaning for such a document).

> +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 en=
ough
> +that not everybody will agree on the direction to take.

I think it=E2=80=99s about community input and consent (as opposed to =E2=
=80=9Ceverybody
will agree=E2=80=9D).

> +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 environme=
nt=3D
> +   (Add 'guix shell' to subsume 'guix environment', #50960)
> + + introduction of authentication mechanism (Trustable "guix pull", #228=
83)
> + + 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)

I mostly agree with Chris=E2=80=99s comments here.

> +* 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.

I think we should be explicit about whether only code is subject to RFCs
or whether non-code matters may also be subject to RFCs: processes and
governance, documentation, web site, l10n workflow, Outreachy/GSoC
internship management, etc.

I don=E2=80=99t have an opinion yet on whether that should be the case for =
all
of these topics, though my initial impression is that it would work well
for the documentation and web site for instance.

> +  + Any change that modifies Guix API

We=E2=80=99ll have to be clearer here because there many interfaces in Guix.
There=E2=80=99s the command-line interface, and there are Scheme interfaces.

The latter is split into rather different categories: user-facing
modules (those one uses from a manifest, from a Home/System config, or
from a package module), package and service modules, modules external
libraries and tool may rely on ((guix store), (guix packages), (guix
derivations), etc.), and the large family of modules that are mostly
used internally ((guix cpio), (guix docker), (guix cve), =E2=80=A6).

The expectations are different here: we=E2=80=99re probably much less stric=
t for
the last category than we are for the first ones.

So, as an attempt to capture that, I would at least word it along these
lines:

  Changes that modify user-facing interfaces: command-line interfaces
  and core Scheme interfaces that external libraries and programs may
  rely on.

> +  + Big restructuring of packages

Wouldn=E2=80=99t this overlap with teams?

For example, I would expect the Python team to be responsible for
Python-wide changes, but then I agree that it would be nice to have
representatives from other teams (maybe =E2=80=98core-packages=E2=80=99?) b=
e in the loop
for wide-ranging changes.

> +  + Introduction or removal of subcommands

Might be covered with wording as shown above.

> +Certain changes do not require an RFC:
> +
> +  - Adding, updating packages, removing outdated packages
> +  - Fixing security updates and bugs that don't break interfaces

At first sight one might get the feeling that few changes are exempt
from RFCs; we should instead clarify that this is the opposite.

Chris=E2=80=99 idea of expressing RFC-worthiness in terms of =E2=80=9Ccost =
of reverting=E2=80=9D
or cost of eventually changing our minds better captures the intent.

> +** 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 les=
s.

Terminology: what about =E2=80=9Cproponent=E2=80=9D (the person who writes =
the proposal
and takes responsibility for pushing it forward) and =E2=80=9Csupporters=E2=
=80=9D (there
could be several of them)?

I think we need a clear automaton here:

  submitted --(7d)--> draft --(30d=E2=80=9360d)--> withdrawn | final

Meaning that: the initial patch (sent to guix-patches) would be applied
or rejected by an =E2=80=9CRFC editor=E2=80=9D (?) within 7 days, the comme=
nt period
would be at least 30 days and at most 60 days, and after the comment
period the proposal would move either to =E2=80=9Cwithdrawn=E2=80=9D state =
(meaning more
discussion is needed and/or consensus could not be achieved and/or
proponent gave up) or to =E2=80=9Cfinal=E2=80=9D state (proponent and other=
s may submit
patches implementing what they proposed within say 6 months following
approval).

Of course we can tweak these details but anyhow the automaton and
timeline should be clear.

I took inspiration from:

  https://srfi.schemers.org/srfi-process.html

> +** Merging the outcome
> +
> +Whoever merges the successful RFC should do the following:

It=E2=80=99s unclear to me what =E2=80=9Cmerging the RFC=E2=80=9D mean.  Pr=
esumably the text
itself was merged from the start.

> +** 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.

I=E2=80=99d go for one format, preferably Markdown because we have a librar=
y to
parse it.

> +** 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 don=E2=80=99t think this belongs here.  I=E2=80=99m also not sure the RFC=
 process
document has to follow the RFC template: it looks nice to our nerd
minds, but it might be unhelpful.

I=E2=80=99ll leave out the template for now.

Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#66844] [PATCH 0/1] Add Request-For-Comment process.
References: <cover.1698747252.git.zimon.toutoune@HIDDEN>
In-Reply-To: <cover.1698747252.git.zimon.toutoune@HIDDEN>
Resent-From: =?UTF-8?Q?No=C3=A9?= Lopez <noe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 31 Oct 2024 13:31:02 +0000
Resent-Message-ID: <handler.66844.B66844.17303814503510 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66844
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 66844 <at> debbugs.gnu.org
Received: via spool by 66844-submit <at> debbugs.gnu.org id=B66844.17303814503510
          (code B ref 66844); Thu, 31 Oct 2024 13:31:02 +0000
Received: (at 66844) by debbugs.gnu.org; 31 Oct 2024 13:30:50 +0000
Received: from localhost ([127.0.0.1]:42035 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t6VGD-0000uY-8n
	for submit <at> debbugs.gnu.org; Thu, 31 Oct 2024 09:30:49 -0400
Received: from smtp.domeneshop.no ([194.63.252.55]:41147)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <noe@HIDDEN>) id 1t6VG9-0000uQ-F2
 for 66844 <at> debbugs.gnu.org; Thu, 31 Oct 2024 09:30:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xn--no-cja.eu; s=ds202402; h=Content-Transfer-Encoding:Content-Type:
 MIME-Version:Message-ID:Date:Subject:To:From:From:Sender:Reply-To:Subject:
 Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=4Ny0LIOnDtaxa9vmdr3OvvQqQsJmZfR9Cs5w+eA8TVc=; b=yNkv9+CSedjaM4SoHvtrrCQfCk
 5OHjkGcxKbqFOcBj15QU456S2OgdCG9SvU+OMLEizadpw/4j9+rmAFEb4FxFut86LnqF/gFCbHxYL
 qt1VfRcTyPsLykC8ACSrnJNICo4qBdIq43162Ti1yoSPmOHcSR6QMQmTxLgxLGeAfR7CtenQz/lSm
 ugl/DMqt9j9viItb6cjGRyBEDryxOL0LRuowr1bwrvs1BOrF0JF+8aKqSqtSSKVMSPCBb4S1nTBXb
 DghGhcy3bEbifA4jvN1rVt1zJDzifgAGvAUZxXVdAaWDBAjK5/SRc3nlW8QPzkcTTu+H+M3DNN1Z7
 +20PmCjg==;
Received: from [163.5.23.109] (port=31299 helo=lignux)
 by smtp.domeneshop.no with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)
 (envelope-from <noe@HIDDEN>) id 1t6VDw-00EAcq-Ga
 for 66844 <at> debbugs.gnu.org; Thu, 31 Oct 2024 14:28:28 +0100
From: =?UTF-8?Q?No=C3=A9?= Lopez <noe@HIDDEN>
Date: Thu, 31 Oct 2024 14:29:31 +0100
Message-ID: <87ikt8764k.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

Happy birthday to the patch! Its probably a good time to look back into
it.  It would be very beneficial as a first step to establishing a new
gouvernance process as recently discussed on guix-devel [1] [2].

>An unsuccessful RFC is *not* a judgment on the value of the work, so a
>refusal should rather be interpreted as =E2=80=9Clet=E2=80=99s discuss aga=
in with a
>different angle=E2=80=9D.  The last state of an unsuccessful RFC is archiv=
ed
>under the directory rfcs/unsuccessful/.

This should say =C2=AB=C2=A0rfc/=C2=A0=C2=BB.

The rest looks good for me, with Christopher and Ludovic=E2=80=99s
recommendations.

Good evening,
No=C3=A9

[1] https://lists.gnu.org/archive/html/guix-devel/2024-10/msg00122.html
[2] https://lists.gnu.org/archive/html/guix-devel/2024-10/msg00155.html

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 12 Dec 2024 17:46:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 12 12:46:05 2024
Received: from localhost ([127.0.0.1]:40185 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLnGH-0007Bu-Ax
	for submit <at> debbugs.gnu.org; Thu, 12 Dec 2024 12:46:05 -0500
Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:7889)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1tLnGF-0007BJ-Gx
 for control <at> debbugs.gnu.org; Thu, 12 Dec 2024 12:46:04 -0500
Authentication-Results: mail2-relais-roc.national.inria.fr;
 dkim=none (message not signed) header.i=none;
 spf=SoftFail smtp.mailfrom=ludo@HIDDEN;
 dmarc=fail (p=none dis=none) d=gnu.org
X-IronPort-AV: E=Sophos;i="6.12,229,1728943200"; d="scan'208";a="198894413"
Received: from 91-160-117-201.subs.proxad.net (HELO ribbon) ([91.160.117.201])
 by mail2-relais-roc.national.inria.fr with
 ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2024 18:45:58 +0100
Date: Thu, 12 Dec 2024 18:45:57 +0100
Message-Id: <875xno94mi.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
Subject: control message for bug #66844
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

severity 66844 important
quit

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 12 Dec 2024 17:46:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 12 12:46:10 2024
Received: from localhost ([127.0.0.1]:40188 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tLnGL-0007CF-OZ
	for submit <at> debbugs.gnu.org; Thu, 12 Dec 2024 12:46:09 -0500
Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:7889)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1tLnGJ-0007BJ-LY
 for control <at> debbugs.gnu.org; Thu, 12 Dec 2024 12:46:07 -0500
Authentication-Results: mail2-relais-roc.national.inria.fr;
 dkim=none (message not signed) header.i=none;
 spf=SoftFail smtp.mailfrom=ludo@HIDDEN;
 dmarc=fail (p=none dis=none) d=gnu.org
X-IronPort-AV: E=Sophos;i="6.12,229,1728943200"; d="scan'208";a="198894423"
Received: from 91-160-117-201.subs.proxad.net (HELO ribbon) ([91.160.117.201])
 by mail2-relais-roc.national.inria.fr with
 ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2024 18:46:07 +0100
Date: Thu, 12 Dec 2024 18:46:07 +0100
Message-Id: <874j3894m8.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
Subject: control message for bug #74736
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

merge 74736 66844
quit

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#66844] (no subject)
References: <cover.1698747252.git.zimon.toutoune@HIDDEN>
In-Reply-To: <cover.1698747252.git.zimon.toutoune@HIDDEN>
Resent-From: =?UTF-8?Q?No=C3=A9?= Lopez <noe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 20 Feb 2025 13:39:01 +0000
Resent-Message-ID: <handler.66844.B66844.17400587034806 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66844
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: control <at> debbugs.gnu.org, 66844 <at> debbugs.gnu.org
Received: via spool by 66844-submit <at> debbugs.gnu.org id=B66844.17400587034806
          (code B ref 66844); Thu, 20 Feb 2025 13:39:01 +0000
Received: (at 66844) by debbugs.gnu.org; 20 Feb 2025 13:38:23 +0000
Received: from localhost ([127.0.0.1]:34613 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tl6kx-0001FQ-0m
	for submit <at> debbugs.gnu.org; Thu, 20 Feb 2025 08:38:23 -0500
Received: from smtp.domeneshop.no ([2a01:5b40:0:3006::1]:51840)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <noe@HIDDEN>)
 id 1tl6ku-0001EX-Kt; Thu, 20 Feb 2025 08:38:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xn--no-cja.eu; s=ds202502; h=Content-Type:MIME-Version:Message-ID:Date:To:
 From:From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:
 Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description:
 Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
 In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=npcrLD4kahvPWr/Zm9OkjZ2T5ECQNr7GePtBuVdCAhI=; b=Y4gRBupnBbK8GpVZa1UwUuKgVx
 n3bDOjECLJWQW1C72D8T3ro6AxUVDCmaPybOc1r5T0v3CNrVcm+VIHKQNCaOwDQQnBEJlK/pAZbQ4
 5FwWdVc1JJxNifMw7DDKRo/EvqkSHllZdTVgkKbPfDxkqUuOolrWfPQq4cz9ZFri4IA4LL/BK1Rj3
 G2dBz1rjuWs1+qx0qkXsYjmBB8frThMWYp7IMhKzVUcRlSnSu6FNi8/bgPRj81O1ODQXG26DMcHJ7
 lX4cFMBf595HvgC7jSXUg8zPotMEjk22EMrbQiJZM5IU44K64wQdz0OEo0S0TxbXD+okw2Z1/Ifd4
 PeOIFKdQ==;
Received: from smtp by smtp.domeneshop.no with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)
 id 1tl6ko-006ZOL-I0; Thu, 20 Feb 2025 14:38:14 +0100
From: =?UTF-8?Q?No=C3=A9?= Lopez <noe@HIDDEN>
Date: Thu, 20 Feb 2025 14:38:13 +0100
Message-ID: <87ikp4ka7u.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  close 66844 thanks 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

close 66844
thanks

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 20 Feb 2025 13:38:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 20 08:38:23 2025
Received: from localhost ([127.0.0.1]:34615 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tl6kx-0001FT-9y
	for submit <at> debbugs.gnu.org; Thu, 20 Feb 2025 08:38:23 -0500
Received: from smtp.domeneshop.no ([2a01:5b40:0:3006::1]:51840)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <noe@HIDDEN>)
 id 1tl6ku-0001EX-Kt; Thu, 20 Feb 2025 08:38:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=xn--no-cja.eu; s=ds202502; h=Content-Type:MIME-Version:Message-ID:Date:To:
 From:From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:
 Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description:
 Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
 In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=npcrLD4kahvPWr/Zm9OkjZ2T5ECQNr7GePtBuVdCAhI=; b=Y4gRBupnBbK8GpVZa1UwUuKgVx
 n3bDOjECLJWQW1C72D8T3ro6AxUVDCmaPybOc1r5T0v3CNrVcm+VIHKQNCaOwDQQnBEJlK/pAZbQ4
 5FwWdVc1JJxNifMw7DDKRo/EvqkSHllZdTVgkKbPfDxkqUuOolrWfPQq4cz9ZFri4IA4LL/BK1Rj3
 G2dBz1rjuWs1+qx0qkXsYjmBB8frThMWYp7IMhKzVUcRlSnSu6FNi8/bgPRj81O1ODQXG26DMcHJ7
 lX4cFMBf595HvgC7jSXUg8zPotMEjk22EMrbQiJZM5IU44K64wQdz0OEo0S0TxbXD+okw2Z1/Ifd4
 PeOIFKdQ==;
Received: from smtp by smtp.domeneshop.no with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)
 id 1tl6ko-006ZOL-I0; Thu, 20 Feb 2025 14:38:14 +0100
From: =?utf-8?Q?No=C3=A9_Lopez?= <noe@HIDDEN>
To: control <at> debbugs.gnu.org, 66844 <at> debbugs.gnu.org
Date: Thu, 20 Feb 2025 14:38:13 +0100
Message-ID: <87ikp4ka7u.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  close 66844 thanks 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

close 66844
thanks

Last modified: Thu, 20 Feb 2025 13:45:03 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.