GNU bug report logs - #74736
[PATCH v2 0/1] Add Request-For-Comment process.

Previous Next

Full log

Message #24 received at 74736 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, Noé
 Lopez <noe <at> xn--no-cja.eu>
Cc: 74736 <at> debbugs.gnu.org, Christopher Baines <mail <at> cbanes.net>,
 Steve George <steve <at> futurile.net>
Subject: Re: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.
Date: Thu, 12 Dec 2024 20:47:17 +0100

Hi all,

Thanks Noé!  I added you as co-supporter; someone definitively
required. ;-)

Thanks Steve for reaching me some weeks end ago.

Well, based on Noé’s v2, I polished some comments and sent v3; based on
what my follow up started weeks (months?) ago.


On Thu, 12 Dec 2024 at 19:14, Ludovic Courtès <ludo <at> gnu.org> wrote:

> 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 <package> record type and/or its interfaces;
>   - adding or removing a ‘guix’ 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 “When To Follow
> This Process”; maybe just keep it in one place, under “When To Follow…”?

I think it helps to understand.  Concrete examples always help, IMHO.

Therefore, I propose what your wording.  Then, past examples where this
RFC process would have been helpful, I guess.

>> +  1. Clone https://git.savannah.gnu.org/git/guix.git
>
> I would suggest a separate repo.

Bah since we are putting all there… When you see etc/ ;-)


>> +** Decision making: consensus
>
> … and drop this.

I think it makes more sense to have the Decision Making as RFC and then
the manual refers to it, and not the converse. ;-)

Therefore, I would keep the section here.  And once we are done, letting
the manual as-is, I would link to RFC.

What defines the Decision Making *is* RFC and not the manual. ;-)


> Maybe we should define the role of “RFC editors” (or “RFC team”?), which
> would be the people responsible for doing those changes.

I’ve drop this “RFC teams“ or “RFC editors” because in my initial idea,
this is the aim of “co-supporter(s)”.  See the relevant section; does it
need to be improved?


>> +** Backward Compatibility
>> +
>> +None.
>> +
>> +** Forward compatibility
>
> I’m not sure what’s expected in these sections.  Maybe “Compatibility
> Considerations” would be more appropriate?

Yes, maybe “Compatibility Consideration”.  It needs to be in agreement
with the template.

>> +* Unresolved questions
>
> I think these two sections in the context of this foundational document
> look a bit ridiculous.  :-)  But maybe that’s okay?

I think that the first RFC must respects what it asks to other RFC. ;-)

And if the consensus is not reached, we need a place to summarize the
unresolved discussion, no?


Again, thanks Noé and Steve for taking care of that!

Cheers,
simon

Previous Next

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