Hi Ludo,
On Wed, 27 Oct 2021 at 23:22, Ludovic Courtès <l...@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.
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-l...@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.
