unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Bengt Richter <bokr@bokr.com>
To: zimoun <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Time for a request-for-comments process?
Date: Thu, 28 Oct 2021 12:33:48 +0200	[thread overview]
Message-ID: <20211028103348.GA3297@LionPure> (raw)
In-Reply-To: <86lf2dee1x.fsf@gmail.com>

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 <ludo@gnu.org> 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]:
> 
>     <https://debbugs.gnu.org/rrd/guix-patches-oc.png>
> 
> 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: <https://yhetil.org/guix/87mtn56mzg.fsf_-_@inria.fr>
> 2: <https://debbugs.gnu.org/rrd/guix-patches.html>
> 3: <https://debbugs.gnu.org/rrd/guix-patches-oc.png>
> 4: <http://issues.guix.gnu.org/issue/45692>
> 
> 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: <https://yhetil.org/guix/20210716155009.32118-1-ludo@gnu.org/>
> 
> 
> *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


  reply	other threads:[~2021-10-28 10:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 21:22 Time for a request-for-comments process? Ludovic Courtès
2021-10-27 22:28 ` Katherine Cox-Buday
2021-10-28  0:07   ` Thiago Jung Bauermann
2021-10-29 15:08     ` Ludovic Courtès
2021-10-30 15:57       ` zimoun
2021-11-09 16:52         ` Ludovic Courtès
2021-11-09 18:01           ` zimoun
2021-11-09 21:10             ` Julien Lepiller
2021-10-27 23:47 ` jbranso
2021-10-27 23:48 ` jbranso
2021-10-28  8:42 ` zimoun
2021-10-28 10:33   ` Bengt Richter [this message]
2021-10-28 17:06     ` Tobias Platen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211028103348.GA3297@LionPure \
    --to=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).