From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id EOthG72AemFnEAEAgWs5BA (envelope-from ) for ; Thu, 28 Oct 2021 12:51:41 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id iAUfF72AemFYYgAAB5/wlQ (envelope-from ) for ; Thu, 28 Oct 2021 10:51:41 +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 AEA9D2CE72 for ; Thu, 28 Oct 2021 12:51:40 +0200 (CEST) Received: from localhost ([::1]:40020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mg30V-0008On-Ks for larch@yhetil.org; Thu, 28 Oct 2021 06:51:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg2jh-0001Fh-02 for guix-devel@gnu.org; Thu, 28 Oct 2021 06:34:17 -0400 Received: from imta-38.everyone.net ([216.200.145.38]:35256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg2jd-00047G-MW; Thu, 28 Oct 2021 06:34:16 -0400 Received: from pps.filterd (omta003.sj2.proofpoint.com [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 19SAR6rD004088; Thu, 28 Oct 2021 03:34:06 -0700 X-Eon-Originating-Account: YnxKAyVftsdegpqSmTFmN6gIqhfWazbFGVlM89cRZls X-Eon-Dm: m0116293.ppops.net Received: by m0116293.mta.everyone.net (EON-AUTHRELAY2 - 5a81d390) id m0116293.616b210d.16c6a1; Thu, 28 Oct 2021 03:34:04 -0700 X-Eon-Sig: AQMHrIJhenycKLFX/gIAAAAD,def72c4f2f0aa742c3c1904eacd898a7 X-Eip: mX6LBQ04TT--Vl8wGXFEwmjcd-XoenGwPvTaBK_jeCg Date: Thu, 28 Oct 2021 12:33:48 +0200 From: Bengt Richter To: zimoun Subject: Re: Time for a request-for-comments process? Message-ID: <20211028103348.GA3297@LionPure> References: <87cznqb1sl.fsf@inria.fr> <86lf2dee1x.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86lf2dee1x.fsf@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-GUID: Ci8Hgtw49-UYpm0xJ88NV_bRvhaxazWT X-Proofpoint-ORIG-GUID: Ci8Hgtw49-UYpm0xJ88NV_bRvhaxazWT X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-28_01:2021-10-26, 2021-10-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1034 mlxscore=0 phishscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2110280057 Received-SPF: pass client-ip=216.200.145.38; envelope-from=bokr@oz.net; helo=imta-38.everyone.net X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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: , Reply-To: Bengt Richter Cc: Guix Devel 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=1635418300; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=qszKJQbDuBnRmb5IBaAtN4HmrA5X+C2UHzMwYPqMaGs=; b=dZl2vP5BRqzj2yFeScvw2gtzavIBqeg9c9WMd07OYKCi/gmO+MGH1AFp/Qpo96GiSRi+Bc 2JjBkm1DNIJb5BBeDODpKdFcxb0udxtsHOTDCgUp8MTicdmyFCjCt7u1H1PI1KwPxsZs2B P3Ubanj8UMrwAM5uT97QrH4LyyhiNECa2kt372ThwzGm7AF2xhZ46mCb/mJg5vgo4R6lp6 BFGKMIjiXTC34/fIGqCZxnOeqg3SSw5KB7YP4VdDZYeRPJYUBTPvraPWtCl5kdzDJ5dVBd 4Avhw5MPeWwx+NoSBLTPWy9nIN5FZTdz004XhIvZu+LANbd8YyTIIrvjwxyfKA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1635418300; a=rsa-sha256; cv=none; b=daqk2KPRSQ6iRmdsogRDTQU79FOIa+YTL0tGyW/Hp3NhgnGfIJODEn+1Tw3ZId1jc5+hQp ObXVYHExOFuEb02HGgP4Y4ueIjip7piT50Bh8xOAEWDQeuftfZ+anM5AU/yPLEAJXGKb8Q tDyGcr06k6xJWga1Oh3blrq54xYYwxB74bmmXtmTa3lZE5el71xAWhNC4Qx18krEYXMf3h mrQgeiLkR5m4vTTdCpJMsEjywgbWU2yuzKon8vS+GGaoUks5KxFrnuefN0HWZr5pXpIMRh fborfseBjwhNUsVshQV+Qs8X6Cdh/g/1Vq81Ogf85//8UMDqbKNTTPBtBAdOdQ== 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: -0.92 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: AEA9D2CE72 X-Spam-Score: -0.92 X-Migadu-Scanner: scn0.migadu.com X-TUID: AAVLw43mtLxh 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. > -- Regards, Bengt Richter