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

Previous Next

Package: guix-patches;

Reported by: Noé Lopez <noe <at> xn--no-cja.eu>

Date: Sun, 8 Dec 2024 12:29:02 UTC

Severity: important

Tags: patch

Merged with 66844

Done: Noé Lopez <noe <at> xn--no-cja.eu>

Bug is archived. No further changes may be made.

Full log


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

From: Hartmut Goebel <h.goebel <at> crazy-compilers.com>
To: Simon Tournier <zimon.toutoune <at> gmail.com>, 74736 <at> debbugs.gnu.org
Subject: Re: [bug#74736] Re v8 of Add Request-For-Comment process.
Date: Thu, 16 Jan 2025 20:50:34 +0100
[Message part 1 (text/plain, inline)]
Hi,

tanks for the updated version.

> On Sun, 12 Jan 2025 at 16:57, Hartmut Goebel<h.goebel <at> crazy-compilers.com> wrote:
>
>> Section "How the Process Works", number 2: Is –sequence number obvious
>> enough? If the GCD is not pushed to the repo right after creating,
>> other authors need to look at the patches-mailinglist.
> The “sequence number“ of GCD is incremented once the proposal is
> ‘Submitted’.

The current text does not state this. Rather it implies, the sequence 
number is to be picked when creating the draft ("How the Process Works", 
number 2). So if two persons draft a GCD at nearly the same time, how to 
prevent both are picking the same number? (See proposal below.)

It also came to my mind, that the text does not explain who is pushing 
the patch to the GCD repo and when (at which point in the process). 
Proposed text:

   At the end of section "Submission Period":

   If the proposal is "submitted", the author updates the sequence
   number and the state in the patch, applies the patch and pushes the
   change to the main branch of the GCD repo. The commit message should
   read "Submit GCD XYZ: Short Title". See "Merging The (final) GCD)".
   — The next step is the *discussion period*.

   If the proposal is "canceled" or "withdrawn", the author closes the
   "guix-patches" issue and nothing is pushed to the GCD repo. The
   process ends here.

> The complete sentence reads: « The GCD must not be prospective; it must
> formalize an idea and sketch a plan to implement it, even if not all
> details are known. ».  Because the GCD must not be a brainstorming
> session or a vague idea but a concrete proposal.
>
> Well, I am not native and ‘prospective’ sounds close to French. :-)

I'm not native either and I simply don't understand the meaning of "not 
be prospective" - even in conjunction with the remaining part. I suggest 
to either use a different less eloquent wording, rephrase it like you 
did, or as a last resort, remove this phrase.

Also for me "formalize" sounds like the wrong term, as it translates to 
"write a [math, chemistry, etc.] formula", "make official" or "fix in a 
contract". Anyhow, this is what shall be expressed?

Proposal:

   The GCD must describe a concrete idea and sketch a plan to implement
   it, even if not all details are known. The GCD must not be a
   brainstorming session or a vague idea but a concrete proposal.

>> Section "How the Process Works", number 4: It should be states
>> explicitly that the patch is for/against guix-consensus-documents.
> I’m not sure to get the comment.  Is it not clear with
>
>   1. Clone https://…/guix-consensus-documents.git

It was not oblivious to me. This is why I'd rather state i explicitly.

>> Section "Timelime", Flowshart: Some kind of "declined" is missing.
> Updated.

"Canceled" is the term used in "Submission Period". Sorry for the confusion.


>
>> Section "Submission Period": withdraw and can resubmit "possibly under
>> a new GCD number". Why possibly? What are the rules whether a new
>> number has to be used?
> Once the GCD is “Submitted”, it ends with the state either “Accepted” or
> “Widthdrawn”.  Therefore, if a “Submitted” GCD is “Widthdrawn”, then a
> new “Submission” gets a new number (if the new becomes “Submitted”).
>
> That’s the idea.

Thus the word "possibly" (translates to "maybe", "perhaps"), has to be 
removed from the sentence, right?

>> Section "Discussion Period": Can the period be extended? What happens
>> if there is still heavy discussion aber 60 days?
> IMHO, it’s better if we keep a bounded period.  Somehow, if after 60
> days we are not able to have a consensus, it means the idea is not ready
> yet.  Based on this output, nothing prevent to resubmit later once new
> and a fresh point of view comes in.

In <https://issues.guix.gnu.org/issue/74736#58> Ludo wrote: "It has to 
be at most 60 days, I think that’s quite clear."

Either way, this need to be stated more explicit.

>> Section "Deliberate period": "GCD acceptence" and "withdrawal does not
>> necessarily" should go out of this section into as more general
>> part. Mayby into "Decision Making" (see my next point on this).
> I do not know…
>
>> Section "Deliberate period": IMHO if a vast number of team members
>> disapprove the proposal it should be taken as rejected.
> There is no formal distinction between ’withdrawn’ because the author
> decides to do so or because the consensus leads to a disparagement.
>
> Maybe we could introduce that have four potential states for the GCD
> (accepted or deprecated, rejected, withdrawn).
Rethinking this: Since we are seeking consensus, it does not actually 
matter whether the GCD was rejected or withdrawn.

And some new points:

Section "Merging Final GCDs" puts the burden of updating the meta-date 
and announcing to a committer. Agreed that the author might not have 
commit permissions to the GCD repo. Anyhow many might abstain from 
committing it there in this case :-)

Section "Merging Final GCDs" uses "committer" in terms of "has commit 
permissions to the GCD repo" – which is different from teh definition in 
roles. Thus a different or more specific term should be used here.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          |h.goebel <at> crazy-compilers.com               |
|www.crazy-compilers.com | compilers which you thought are impossible |
[Message part 2 (text/html, inline)]

This bug report was last modified 90 days ago.

Previous Next


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