From: Julien Lepiller <julien@lepiller.eu>
To: guix-devel@gnu.org, zimoun <zimon.toutoune@gmail.com>,
"Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>,
Katherine Cox-Buday <cox.katherine.e@gmail.com>
Subject: Re: Time for a request-for-comments process?
Date: Tue, 09 Nov 2021 16:10:01 -0500 [thread overview]
Message-ID: <9CEB32F9-01C3-4401-8649-5F5D5A474146@lepiller.eu> (raw)
In-Reply-To: <86o86tnr79.fsf@gmail.com>
Le 9 novembre 2021 13:01:46 GMT-05:00, zimoun <zimon.toutoune@gmail.com> a écrit :
>Hi Ludo,
>
>On Tue, 09 Nov 2021 at 17:52, Ludovic Courtès <ludo@gnu.org> wrote:
>> zimoun <zimon.toutoune@gmail.com> skribis:
>
>>> However, as I said elsewhere, this effort should start be collecting
>>> what do we consider as changes requiring formal process?
>>
>> Agreed, that’s what I meant above.
>
>I meant, based on changed already merged. For instance, on the top of
>my head, some changes that *I* consider requiring a RFC:
>
> - new inputs style
> - guix shell
> - authentication
> - GUIX_EXTENSIONS_PATH (not finished and not documented)
>
>And it would be nice if we could come with a list of such changes. It
>would help for finding patterns – if they are :-) – for examples,
>numbers of people involved in the discussion, time between each reply,
>structure of the cover letters, etc.
>
>
>> I don’t have an answer, but I think we should look at what others are
>> doing, what criteria they use, etc. The Nix RFC process is probably the
>> closest match in terms of application domain, but maybe others are
>> closer to the way we practice decision-making in Guix.
>
>Yeah, for sure, several items need definitions. ;-)
>
> - which kind of change requires a RFC?
At the very least those changes we thought were important enough to add them to the news entries.
> - what is the process?
> - how to decide? Accept or reject?
I think the process could allow for some time to discuss various options and arrive at a concensus. The final implementation might be different from the initial idea.
I suppose this is where we have to look at other project's processes :)
> - who decide?
> - etc.
>
>
>Cheers,
>simon
>
next prev parent reply other threads:[~2021-11-09 21:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 21:22 Time for a request-for-comments process? Ludovic Courtès
2021-10-27 22:28 ` Katherine Cox-Buday
2021-10-28 0:07 ` Thiago Jung Bauermann
2021-10-29 15:08 ` Ludovic Courtès
2021-10-30 15:57 ` zimoun
2021-11-09 16:52 ` Ludovic Courtès
2021-11-09 18:01 ` zimoun
2021-11-09 21:10 ` Julien Lepiller [this message]
2021-10-27 23:47 ` jbranso
2021-10-27 23:48 ` jbranso
2021-10-28 8:42 ` zimoun
2021-10-28 10:33 ` Bengt Richter
2021-10-28 17:06 ` Tobias Platen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9CEB32F9-01C3-4401-8649-5F5D5A474146@lepiller.eu \
--to=julien@lepiller.eu \
--cc=cox.katherine.e@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).