Hi Maxime, Maxime Devos <maximede...@telenet.be> writes:
> Op 12-06-2023 om 03:17 schreef Maxim Cournoyer: >> Hi Maxime, >> Maxime Devos <maximede...@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
