Re: rust-build-system from antioxidant

[Maxime Devos]

Op 12-06-2023 om 03:17 schreef Maxim Cournoyer:
> Hi Maxime,
>
> Maxime Devos <maximedevos@telenet.be> writes:
>
> > Op 02-06-2023 om 20:02 schreef Nicolas Graves:
> > > A few months ago, Maxime Devos worked on a new rust-build-system to
> > > handle a few issues we were experiencing with cargo (see discussions on
> > > antioxidant in guix-devel).
> > > A month ago, we discussed about the possibility of the integration
> > > in
> > > core guix, and the required steps. Maxime and I had a different
> > > approach. Maxime highlighted the possibility to make a smooth transition
> > > but once that would require many gradual changes and deprecation. My
> > > approach was that since we'll have to eventually migrate all packages to
> > > rust-build-system, and since we can freeze all former rust packages in
> > > an archive channel, I would be clearer to make the transition at once.
> > > [...]
> >
> > Actually, I started out with the non-gradual approach, but that was
> > overruled by Ludo', IIRC.
>
> Did you perhaps meant to say that it was disagreed with, or at worst
> "blocked by"?

Yes.  Overruling is a form of blocking, and blocking by authority 
(whether de facto or de jure) is overruling.

> There should not be a notion of 'overruling' in our
> contribution processes (unless the Guix co-maintainers have to step in
> as a last resort) if all participants strive to build consensus, as
> mentioned in info '(guix) Commit Access':
>
>     It is expected from all contributors, and even more so from committers,
>     to help build consensus and make decisions based on consensus.  To learn
>     what consensus decision making means and understand its finer details,
>     you are encouraged to read
>     <https://www.seedsforchange.org.uk/consensus>.
>
> I thought I knew what consensus meant myself, but the above link helped
> me to re-frame a few things in a way that is more conducive to building
> consensus.

In my experience, Ludovic often doesn't actually practice that, though.
For example, the thread of the patch you sent at 
<https://issues.guix.gnu.org/51427> is a good example of this, pretty 
much everyone (except Ludo') agreed that the provided patch is good.

People pointed out how Ludo' multiple time missed the point of the 
patch.  Yet, Ludo' kept missing the point, e.g. consider:

> [Liliana Marie prikler wrote on 18 jul 2022 19:03]
> Am Montag, dem 18.07.2022 um 15:57 +0200 schrieb Ludovic Courtès:
> Toggle quote (7 lines)
> > Hello,
> >
> > With commit 472a0e82a52a3d5d841e1dfad6b13e26082a5750 (Nov. 2021),
> > partially fixing <https://issues.guix.gnu.org/24937>, there is
> > hopefully less pressure to skip the remove-unused-links phase.
> >
> > Should we close this issue?
> As a hard disk user, I'm leaning towards "no".  In fact, I recently
> encountered a case where I think I might want to skip it even if not
> deleting "specific items".  [...

> [Ludovic]
> I agree that we should strive to have good performance on that kind of
> hardware too, but I don’t know how to get there.

That's what the patch is for:

> [Liliana]
> [...]
> > I agree that we should strive to have good performance on that kind
> > of hardware too, but I don’t know how to get there.
> I don't think deleting links will ever be fast on that disk.  But what
> I've been saying the whole time is that I don't always need the links
> deleted.  I think adding "expert" switches to skip these phases might
> actually be enough – after all, if I ever do want to run a full GC, the
> information ought to be the same, no?

[A remainder by me that Ludovic is missing the point]
> [...] The point isn't to work-around slow "deleting unused links" 
> implementation, but rather to avoid inherit slowness of deleting 
> everything when deleting a few things suffice [...]
> [...]
> Apologies for being elliptic.  My point here, as has been discussed
> earlier in this thread, is that we can’t just skip that phase or we’d
> simply leave files around without actually deleting them.

As repeatedly explained in different ways previously, we can, in fact, 
just do this and these consequences are unproblematic.  This is again 
explained in different ways in a response by Liliana and me.

Given that a few of the participants that wanted the patch in some form, 
are actually committers yet didn't commit it even though there was 
consensus, and that de facto Ludo' has authority and disagreed with the 
patch, the only conclusion I can draw from this, is that Ludo' 
effectively overruled the consensus with their (de facto) authority.

Whether this was intentional or not, the effect was the same.

(Technically ‘https://www.seedsforchange.org.uk/consensus#block’ allows 
for an unilateral block, but it later writes ‘However it provides a 
safety net for situations where a proposal would seriously hurt the 
group of people in it’, which doesn't apply at all here.)

This is not the antioxidant stuff, but it should serve as an explanation 
on why I do not believe that Ludovic practices consensus.  There are 
also a few other examples/threads that look suspect to me, but they are 
very ambiguous/not clear-cut.

Greetings,
Maxime.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature