[bug#65866] Toward RFC? (was Re: [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts)

[Simon Tournier]

Hi Ludo,

We are not on the same wavelength about some technical parts.  It does
not really matter – we could tune our frequency separately on some
random occasions. :-)

However…

On Sun, 1 Oct 2023 at 17:02, Ludovic Courtès <ludo@gnu.org> wrote:

> I think it’s important in these discussions to make sure we start from a
> shared understanding so we can remain focused and productive.

…I am, between sad and upset, by this part.  It appears to me unfair or
uncalled for.

« A group using consensus is committed to finding solutions that
everyone actively supports, or at least can live with. » [1].  And I am
sorry to say that we have a failure here; at the root (Guile-GnuTLS bug
report).  And it is a group failure.

Elsewhere in this thread,, I have expressed « I am not convinced that we
reached a consensus about this series. ».  Why no one is asking if I am
blocking this patch?  Anyway!

Thinking more than twice about why it bothers me.  If I feel a failure
about the consensus, then it is because the process fails from my point
of view.  Why?  Because an implementation detail is missing.  It had
been expressed several times.  Notably:

        Time for a request-for-comments process?
        Ludovic Courtès <ludo@gnu.org>
        Wed, 27 Oct 2021 23:22:50 +0200
        id:87cznqb1sl.fsf@inria.fr
        https://lists.gnu.org/archive/html/guix-devel/2021-10
        https://yhetil.org/guix/87cznqb1sl.fsf@inria.fr

And this kind of change « Add Git as hard dependency » should have been
part of such process, IMHO.  Because considering how the current
decision process works, it is impossible to get this “shared
understanding” if you have not been here at the right moment.

How can I acquire this shared understanding?  For example, you said that
Git or TLS or etc. on daemon side are not part of the TCB because they
are used for fixed-output derivations, I disagree and I still think it
is incorrect.  The problem is not my disagreement – I can live with it,
as many others ;-) – no, the problem is that you refer to implicit
decision that I cannot digest, question or ask explanations.  Somehow, I
do not have some gauge for evaluating my own expectations.  It appears
to me that this patch falls under similar circumstances as an idea
expressed here:

        [bug#61894] [PATCH RFC] Team approval for patches
        Ludovic Courtès <ludo@gnu.org>
        Wed, 01 Mar 2023 17:13:28 +0100
        id:878rgga1qv.fsf@inria.fr
        https://lists.gnu.org/archive/html/guix-devel/2023-03
        https://yhetil.org/guix/878rgga1qv.fsf@inria.fr

Now, Guix is probably reaching a point where we deserve more structure
without much burden for making decisions about changes of some category.

Therefore, let turn my own frustration here into a concrete proposal, I
will send this week a Request-For-Comment process inspired by Rust, Nix
and Haskell ones.

Cheers,
simon

1: https://www.seedsforchange.org.uk/consensus
2: https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/