Re: rust-build-system from antioxidant

[Maxim Cournoyer]

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> 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.
>

[...]

> 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.

Let's avoid directly criticising ourselves and try to discuss what I
think has more value, which is coming to a better understanding of the
situation and how the perceived deadlock could be undone.  Consensus is
not a majority vote; all parties have to walk the extra mile to reach a
common ground.  I think the object there was from a semantic point of
view: we'd have a 'garbage collection' command (guix gc) which wouldn't
collect any garbage!  It's a valid objection, although its importance in
the narrow use case presented was not agreed by all parties.

A consensus-based outcome could be to add a new option to guix gc,
e.g. '--invalidate', which would be documented as "invalidate
(de-register from the Guix database) rather actually delete from the
store".  If that's still argued semantically unclear we could go with a
dedicated 'guix invalidate', although that seems overkill to me.

This is a bit more work than the 1 line change initially suggested, but
I think we can agree that'd be a more general/better solution.  Such is
the trade-off of consensus-based decision making (requires more
effort/slower moving but with a higher quality outcome).

-- 
Thanks,
Maxim