From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AEHfG9vYemGHVwAAgWs5BA (envelope-from ) for ; Thu, 28 Oct 2021 19:07:39 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id OUuHF9vYemEUXAAAB5/wlQ (envelope-from ) for ; Thu, 28 Oct 2021 17:07:39 +0000 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 EB904D3A7 for ; Thu, 28 Oct 2021 19:07:38 +0200 (CEST) Received: from localhost ([::1]:58916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mg8sL-0006kU-5a for larch@yhetil.org; Thu, 28 Oct 2021 13:07:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg8rn-0006aF-MY for guix-devel@gnu.org; Thu, 28 Oct 2021 13:07:03 -0400 Received: from mailout1.hostsharing.net ([2a01:37:1000::53df:5fcc:0]:48703) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg8rk-00023r-Dq for guix-devel@gnu.org; Thu, 28 Oct 2021 13:07:03 -0400 Received: from h20.hostsharing.net (h20.hostsharing.net [IPv6:2a01:37:1000::53df:5fec:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by mailout1.hostsharing.net (Postfix) with ESMTPS id BBCFE10190005 for ; Thu, 28 Oct 2021 19:06:54 +0200 (CEST) Received: from anna.fritz.box (55d4c25a.access.ecotel.net [85.212.194.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by h20.hostsharing.net (Postfix) with ESMTPSA id 9B5A23AC4A2 for ; Thu, 28 Oct 2021 19:06:54 +0200 (CEST) Message-ID: <533c17f47f3951b39d9ece2dac161c03d2cc90aa.camel@platen-software.de> Subject: Re: Time for a request-for-comments process? From: Tobias Platen To: guix-devel@gnu.org Date: Thu, 28 Oct 2021 19:06:53 +0200 In-Reply-To: <20211028103348.GA3297@LionPure> References: <87cznqb1sl.fsf@inria.fr> <86lf2dee1x.fsf@gmail.com> <20211028103348.GA3297@LionPure> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: none client-ip=2a01:37:1000::53df:5fcc:0; envelope-from=guix@platen-software.de; helo=mailout1.hostsharing.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1635440859; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=/E6SSlwLrG2M5MzifnWrFwi9rEIwJAkcJ219piTGuQo=; b=DpCVnR3/1yhnlgjJgusU2rH3mVy0nelGHBE9Aro80Ody45G53yp0yJwZL8Mz7C0AZqWIWi smYsDintzl95bB3YAEHQ1IVrNvPT70nKZqJ69Wi56BJ5wfad0nZnlPvWhOW8/Qk/faGpQW yDCf4+Chy+LKxHYUTEqGS72MhZXZuLsa+tPtvLW2XMbjoHezCkl2CIoKowaDdjxykYi6q4 sI38O9YdSR6Ha+nivv2rzPK1hKkEpXROijMxLk1lLlODbTo3hGpdrJtbs9cSXKNAA6OYUc izbNTuh9Of8iozh8OBNcEXCmaCGmJh+WTi5p364AqFX3ZAJijjcw3zc7fSJDYw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1635440859; a=rsa-sha256; cv=none; b=rBRq5IXVbEHWYl1rE86c4ix57gxCUI02ekcaMi/e9StNapeUYjKDPYz1xtLJAyu6KBKAPY Yk41axfmmB2MqJpJeVh7hMga1AH/arWD4HFYWI1ueV8YlfwC+5R0hTlWoQtvRBq7iiGrl1 0TV4zEawr4jQPETeireuVU7KYucbbzktAiZflJ3N4crsO4vC8X4LKjmTOzpaaP1tPaudBN KQBT0xsNtXhj5gz0jLCM5LUOXg5DOln7QszNbzj8Li6C2JsCWMwPoWGWzmTmUUgF++2DJf 5CCi+AG0nThPmkcrT5uubggdhgqOd6gmblANEbYFQOHTBc8g9V2iIW9vcnqhog== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.43 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: EB904D3A7 X-Spam-Score: -1.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: sg+WGh9ySeP7 GNUnet has something similar called the GANA (GNUnet Assigned Numbers Authority) https://git.gnunet.org/gana.git/ On Thu, 2021-10-28 at 12:33 +0200, Bengt Richter wrote: > Hi Zimoun, Ludo, > > On +2021-10-28 10:42:02 +0200, zimoun wrote: > > Hi Ludo, > > > > On Wed, 27 Oct 2021 at 23:22, Ludovic Courtès wrote: > > > > > The recent ‘guix shell’ addition is almost anecdotal technically > > > yet > > > important for the project because users interact with Guix > > > primarily > > > through the CLI.  Adding a new command is a commitment (our users > > > must > > > trust it won’t change overnight), and getting the details wrong > > > could > > > make us fail to honor that commitment. > > > > > > For ‘guix shell’ I left time for comments and repeatedly asked > > > people to > > > comment; yet pushing it was a bit stressful: Did I make a > > > mistake?  Did > > > everyone with a stake in this really have a chance to comment? > > > > Note that the patch received many comments; especially v1.  Then, > > only > > two people commented for v2.  And v3 did not receive any general > > LGTM – > > I sent one for the two trivial parts I reviewed. > > > > For me, one important root of the issue is the review process.  I > > feel > > the balance described in thread «Incentives for review» [1], > > > >         There’s a balance to be found between no formal commitment > > on > >         behalf of committers, and a strict and codified commitment > >         similar to what is required for participation in the > > distros > >         list¹. > > > > is hard to found.  Because, on one hand, the project has to honor > > commitments, and on the other hand, no one as team is committed to > > do > > it. > > > > From my understanding, your message here is interesting because > > somehow > > you did a similar experience as maintainer of what is an usual > > non-committer contributor experience; somehow explained by some of > > my > > soft ramblings from the thread «Incentives for review» [1]. :-) > > Another > > meaningful because similar, IMHO, failure of the review process is > > patch#45692 [4]. > > > > As you know, I did some stats in order to find, or at least > > discuss, how > > to improve the situation grounded on current facts.  Aside, Debbugs > > already provides insightful numbers [2], especially this one [3]: > > > >     > > > > The traffic on guix-patches is quite high and I do not know how > > many > > people subscribe – I guess few.  I hope the discussed improvements > > of > > Mumi will help.  Or perhaps if someone is willing to setup a Guix > > official public-inbox; for example, the instance > > https://yhetil.org/guix > > is providing helpful tools for easily filtering, IMHO. > > > > 1: > > 2: > > 3: > > 4: > > > > Closing parenthesis, back to your question. :-) > > > > > That makes me think it’s perhaps time for a formalized > > > request-for-comments (RFC) kind of process for such “major > > > changes”.  We > > > could draw inspiration from one of the many existing processes: > > > Python’s > > > PEPs, Scheme’s SRFIs, Nix’s RFCs, Rust’s MCPs, etc.  I think a > > > major > > > goal of the process would be to formalize a minimum and a maximum > > > duration under which an RFC is under evaluation, and a mechanism > > > to > > > determine whether it’s accepted or withdrawn. > > > > Aside the usual review process, at least my understanding what the > > review process should be, you are asking for a special flag then > > expose > > materials to various channels of communication, IIUC. > > > > For sure, it appears a good idea. :-) > > > > Concretely, what does it mean “major changes”?  How many of these > > do you > > consider that happened in the recent two past years? > > > > For example, the recent label-less input style [5] is one instance, > > IMHO.  However, I do not remember* if it was discussed outside > > guix-patches. > > > > In addition to the change itself sent to guix-patches with an > > associated > > number, it could be worth to send that information elsewhere. > > > > What would be this elsewhere?  Create another dedicated (low- > > traffic) > > list would scatter the information and I am not convinced it would > > help > > to gain attraction at the moment.  However, it would ease digging > > in the > > future because all would be in only one archive. > >  Wherever "elsewhere" might be, I'd like notification when there is > something >  new to read. > > I'm visualizing a screensaver hook where the screen is restored after > being locked, > like logging in the first or subsequent times, to show an > intermediate popup > before going on as usual. Sort of a dynamic motd (message of the > day). > > What I'd like then, to find out details, is access (CLI or Web > browser) to a relational DB > like the ones supporting online shopping, but in this case I am > shopping for info, and filtering > by e.g. zimoun or ludo instead of Asus or Lenovo, and similarly to > narrow or widen context > for OS or achitecture etc. (I am obviously suggesting something > broader than just "shopping" > for RFC info :) > > The shopping interface could be used to select what info to subscribe > for, > to get notifications about different info "products" or categories. > > > Maybe info-guix could be used.  But it would mean that everybody > > would > > be allowed to this list, when currently the messages landing there > > are > > somehow “highly filtered”.  However, an announce there pointing > > where > > and how to comment could be something helping to get more > > attention. > > Adding a section under Contributing about the process too. > > > > Last, the core question is formalization.  Formalize the process > > (min, > > max duration, expectations of evaluation, mechanism to accept or > > withdraw, i.e., how to revolve different points of views, etc.) > > strongly > > depends on what “major changes” means and how often that happens.  > > Could > > you provide examples of such “major changes”?  It would help for > > drawing > > a sketch of such formalization grounded on concrete examples. > > > > > > Cheers, > > simon > > > > 5: > > > > > > *remember discussion: Personally, I receive all emails to all > > lists. All > > in my Inbox.  Thus, the channel does not mind for my workflow. :-) > > However, dealing with Guix traffic is a daily task – if I am off > > for a > > couple of days or holidays or busy by day job, then I skip some > > based on > > dates or interest.  My trick to deal with such traffic is “just” to > > quickly be able to determine if it is worth, for my interests, to > > jump > > into the details.  If it requires less than 10min to answer, then I > > do > > it (obviously, it always take more time than expected :-)), else if > > I am > > interested in, I mark the email to revisit it later – coupled with > > Org-capture and scheduled TODO tasks.  On the top of that, I use a > > “structured procrastination” approach: do what I am interested in > > at the > > moment, not what it is important or urgent. > > >