From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id sJybDYqVcWdXQwEAe85BDQ:P1 (envelope-from ) for ; Sun, 29 Dec 2024 18:31:38 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id sJybDYqVcWdXQwEAe85BDQ (envelope-from ) for ; Sun, 29 Dec 2024 19:31:38 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=CNDo5SJV; dkim=fail ("headers rsa verify failed") header.d=xn--no-cja.eu header.s=ds202402 header.b="b 3v7558"; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1735497097; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=5vo9nVgq1YDbi7llUNXQriMbJ9eboLD1sKzACU86lsU=; b=TC+8jI6aSF3fmHcORtLTYfy3GXabhsFTa1IGxoZRgedBbegm0btA+wBgmMwSP7VIyY03vF QYxMcDtklYcOAUUf4dG1K0iZZZDyK/44tS8mkqjQyGekw67rXM41N/O87LGvOhdgnvXNv1 N0v609vpO795NWXbBLNiBNjLUANJZE6RjYh4TjYScRAIRB1FLSQWxESXwQfIsFcJ3x0mmR MwNJGT1ykMI/FC+oZORjiJEfR2vjHZrXx/kWlTzaswrk3jskIYbk5I37QDFqZJahky4dE1 DgT6rYdH0JHA9KIR06orZw0wU1qF9nvMF8bx+u5wIg0xK0daatNqFezpbmlC2Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=CNDo5SJV; dkim=fail ("headers rsa verify failed") header.d=xn--no-cja.eu header.s=ds202402 header.b="b 3v7558"; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1735497097; a=rsa-sha256; cv=none; b=DgZ3cYqUc38XrshlNoH7r5bbhPTFknYzvaprwtRELMxDf9mPLiv7ntDR0vxzfJ2Gpb/Ye0 Zv0odz4TOj8TSM57JHVvMg5cU1yNy6Og+TQS7SQLwoQ7yZv7KaMWs++KEkdWw5JDbv6dsz 2NR4deHhiCKr8m3z5E6JO2WqUIdb+OOXlZ/i3Z22tnPTqE4ufcR3oG4KLzZ+j+ORx27R17 OLU9h8E3hACiwzshMqUTf9zH2OrD8D83ANYbS5K8m/Gzo20TDn3xJdo8u7Ll1U/z2GGmG6 BFkN4M8Qy3k863xYpzc+ai64Mk8IVw+M/E8EKD0o23i/tSOdbYDm8ZiYPfDvnw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 66FDF61F66 for ; Sun, 29 Dec 2024 19:31:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRy49-0006LQ-An; Sun, 29 Dec 2024 13:31:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRy46-0006LH-9Y for guix-patches@gnu.org; Sun, 29 Dec 2024 13:31:02 -0500 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tRy46-0004rG-1U for guix-patches@gnu.org; Sun, 29 Dec 2024 13:31:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=5vo9nVgq1YDbi7llUNXQriMbJ9eboLD1sKzACU86lsU=; b=CNDo5SJVu+aTOJS6MF8TOMZ4WcDpy6EkDjOVKAbTAAZZkgwMQX3hJluBgVoxKDr9u3S/3VeyXbO6cpSqfF1+KwI3iebUlpZWVODH9c5ypUCsYZyuNBaR3NRlt1aL/Z74m3VxaLoWyeq3BY6JDP0eLZ9PlIiSQ5MkEZwVHl4OyaWsxjTjwUG1gyW+yBcoiEVC5DB+yc1RL9bloOWs5jt26Q7URXR3Cv/Vi5BMG7E9OTjXGkopLzmHT/6ClQnE2tNwKi7qdqx9Fsaip/LQGwXyWQeePNmPRucKy+38iQTmQOZcBOFa9ZhVpvQVaOD+QKXqiCPGfColryF8qWGOE0spJg==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tRy45-0006Rh-MV for guix-patches@gnu.org; Sun, 29 Dec 2024 13:31:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process. Resent-From: =?UTF-8?Q?No=C3=A9?= Lopez Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 29 Dec 2024 18:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74736 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 74736@debbugs.gnu.org, Simon Tournier Received: via spool by 74736-submit@debbugs.gnu.org id=B74736.173549703224737 (code B ref 74736); Sun, 29 Dec 2024 18:31:01 +0000 Received: (at 74736) by debbugs.gnu.org; 29 Dec 2024 18:30:32 +0000 Received: from localhost ([127.0.0.1]:56131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tRy3b-0006Qu-Cf for submit@debbugs.gnu.org; Sun, 29 Dec 2024 13:30:31 -0500 Received: from smtp.domeneshop.no ([194.63.252.55]:49959) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tRy3Y-0006Qg-3g for 74736@debbugs.gnu.org; Sun, 29 Dec 2024 13:30:30 -0500 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:References:In-Reply-To:Subject:Cc: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=5vo9nVgq1YDbi7llUNXQriMbJ9eboLD1sKzACU86lsU=; b=b 3v75584Zwtgn1ypOFPGgYxnrfW1933euXNvVwG/tQD3NZ9tbnHlvnKHNEqNU+7CPhefdF0xchdC1e 3f8EiXEq5cviokgxmGjl4nPZbYJceKcxtg++6n9kWkGYuXSVUOdOgL6dBuL0tuKz3i+i0xxB10ne/ IPBBRsIJgR6Jmop1E6pEn3iKkJgzx04KYxgGVOvg4GdR2aOhdmehc4podjuahbRDU2Ahbjgd763ho BAZJYe1phNWakr3URaaSPppLB6HKaZbisSnyCTCZEZAQfsmkRM4hsuHC+oMoJPKe8E58ifWW8DpDi PjAQ/cU4pJtZgOB/UN56js63VOJuafn8g==; Received: from smtp by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) id 1tRy3R-005sQq-Lo; Sun, 29 Dec 2024 19:30:21 +0100 In-Reply-To: <87ikraea0f.fsf_-_@gnu.org> References: <87ikraea0f.fsf_-_@gnu.org> Date: Sun, 29 Dec 2024 19:31:46 +0100 Message-ID: <87wmfifii5.fsf@xn--no-cja.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: =?UTF-8?Q?No=C3=A9?= Lopez X-ACL-Warn: , =?utf-8?q?No=C3=A9_Lopez_via_Guix-patches?= From: =?utf-8?q?No=C3=A9_Lopez_via_Guix-patches?= via Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -3.60 X-Spam-Score: -3.60 X-Migadu-Queue-Id: 66FDF61F66 X-TUID: C33TJVGsfiKH Ludovic Court=C3=A8s writes: > Hi No=C3=A9, > > Thanks for this new version. > > No=C3=A9 Lopez skribis: > >> +### Submission (up to 7 days) >> + >> +The author submits their RFC proposal as a regular patch and look for >> +co-supporter(s). See =E2=80=9CCo-supporter=E2=80=9D section. >> + >> +Once the RFC is co-supported, it marks the start of a discussion period. > > [...] > >> +### Last call (up to 14 days) >> + >> +The author publishes a final version of the RFC and a last grace period >> +of 14 days is granted. People are asked to agree or disagree by >> +commenting: >> + >> +- +1 / LGTM: I support >> +- =3D0 / LGTM: I will live with it >> +- -1: I disagree with this proposal >> + >> +At least half of people with commit access must express their voice with >> +the keys above during this last call. We need to be sure that the RFC >> +had been read by people committed to take care of the project, since it >> +proposes an important change. >> + >> +When a positive consensus is reached, the RFC becomes effective. If not, >> +the proposal is archived and the status quo continues. > > It seems unchanged compared to v3. WDYT of my comments, suggestions, > and proposed wording: > > https://issues.guix.gnu.org/74736#9 > > ? As Simon said, I think a vote goes against the principle of consensus. Maybe we can take inspiration from the wayland protocol? If a stakeholder thinks the RFC is complete and satisfactory, they ACK it. If the RFC needs changes, they simply comment and if they are against it they NACK it. Quoting Mike Blumenkrantz: >A NACK for an experimental protocol carries some variation on the followin= g meanings: >This idea is broken and cannot work. >OR >This approach is fundamentally against the core principles or spirit of Wa= yland. >A NACK must be well-justified, as determined by members of the >governance team, who are assumed to be acting in good faith for the best i= nterests of the project. In this way, we can say that an RFC needs a specific amount of ACKs and no NACKs to be merged, ensuring everybody is at least fine with it and the stakeholders are interested enough to ACK it. > > I think we should now make sure we reach consensus on the timeline, and > in particular: > > 1. on the voting process; > > 2. on the submission -> withdrawn transition, in case nobody supports > the RFC. > > Once we have that, we can fine-tune the language and hopefully be done > within a couple of weeks. > > I like the Dot graph you submitted! Here=E2=80=99s an updated version, w= ith a > new submission -> withdrawn arrow (as proposed in the comment above) and > with hopefully clearer names (in particular =E2=80=9CVoting Period=E2=80= =9D rather than > =E2=80=9CLast call=E2=80=9D): > > --8<---------------cut here---------------start------------->8--- > digraph "RFC Timeline" { > submission[label=3D7=C2=A0days>] > comments[label=3D30=E2=80=9360=C2=A0days>] > last_call[label=3D14=C2=A0days>] > withdrawn[label=3DWithdrawn, shape=3Drectangle] > final[label=3DFinal, shape=3Drectangle] >=20=20=20=20=20 > submission -> comments > submission -> withdrawn > comments -> last_call > last_call -> withdrawn > last_call -> final >=20=20=20=20=20 > withdrawn -> submission [label=3D"New version"] >=20=20=20=20=20 > comments -> withdrawn > } > --8<---------------cut here---------------end--------------->8--- > > Thoughts? I agree with that timeline, but I would have just =E2=80=9Cforgotten=E2=80= =9D an RFC that doesn=E2=80=99t pass the submission period, since that would mean it i= s not good enough to be discussed. It can just be kept in the mail archives like any other unfinished idea. A withdrawn RFC would mean keeping it in the rfc/withdrawn directory. This was also why I had proposed the idea of keeping a set of available co-supporters, since any well written RFC should be able to get past the submission period even if you can=E2=80=99t find someone to co-support. Good evening, No=C3=A9