Re: rust-build-system from antioxidant

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 6736 bytes --]



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

This quote is taken out of context -- nowhere I stated or assumed that 
it was a majority vote -- (n - tiny)/n is higher than 50%, and I also 
demonstrated that some other criteria were met.

Please don't ignore the explanation I wrote below all that, let's avoid 
taking quotes out-of-context, and let's avoid ignoring the concerns I 
pointed out in my previous e-mail.

 > [...] try to discuss what I think has more value,
> which is coming to a better understanding of the situation, [...]

I did this in my previous e-mail.  You can bring new discussion from 
another POV if you want to, but why are you ignoring my discussion on 
this matter?

 > [...] all parties have to walk the extra mile to reach a common
 > ground. [...]

This sentence would have more weight if you explained somewhere how this 
wasn't the case in <https://issues.guix.gnu.org/51427>.

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

Ludo' claimed that the resulting patch wouldn't collect garbage:

> I believe the effect is that ‘guix gc -D /gnu/store/…-disk-image’ would
> remove nothing: /gnu/store/.links would still contain a copy of that big
> disk image, so as a result, you’ve freed zero bytes.

On its own, this is a valid objection, but it is false -- it does 
collect some garbage -- it deletes the /gnu/store/ITEM.  This is 
implicitly referred to in:

 > https://issues.guix.gnu.org/51427#4
> [...]  Obviously there needs to be a way of __removing
> single items from the store__, [...]

 > zimoun wrote on 9 Nov 2021 19:10
> [...] Even if the phase is drastically speed up, it would be probably still
> too slow when using the option ’-D’ __remove only one <item>__; or just
> some. [...]

Yet, Ludo' seems to have missed this:

 > [Ludovic Courtès wrote on 17 Nov 2021 11:02]
 > [...]> No; like I wrote, it would have the effect of not deleting 
anything:
 > [...

So I have written it down explicitly:

 > https://issues.guix.gnu.org/51427#25
> Also, it _does_ collect garbage -- it collects the /gnu/store/... item, 
> it just doesn't collect _all_ the garbage (it doesn't collect the 
> individual files in the store item or the things in /gnu/store/.links).

There wasn't any response.

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

"guix gc -D" is already semantically clear -- it deletes a single 
/gnu/store/... item.  IIUC, the patch at 
<https://issues.guix.gnu.org/51427#1> fixes the bug where it also 
deletes more than that.

(IMO both deleting and not deleting the relevant links in 
/gnu/store/.links would be acceptable behaviors, as long as it doesn't 
do more than that.  Also IMO deleting more links is technically a bug, 
but harmless __as long as it's efficient.)

(IIUC, it also deregisters the store item, but that's needed for 
consistency of DB->file system, and deregistering can be considered a 
removal of DB entries, so not really a problem.)

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

It's neither more general nor less general.  If you just deregister it 
from the Guix database, the directory /gnu/store/... exists (unlike 
"guix gc -D") so --invalidate is not more general than "guix gc -D".

If you do "guix gc -D", it will not only deregister the item, but also 
delete the item.  As the removal is not optional, this is not more 
general than "guix gc -D".

Also, I consider "guix gc -D" to be a better solution, because "guix gc 
--invalidate" only deletes entries from the database whereas "guix gc 
-D" also deletes the directory, so "guix gc -D" collects more garbage 
than "guix gc --invalidate".

> Such is
> the trade-off of consensus-based decision making (requires more
> effort/slower moving but with a higher quality outcome).

While it appears to be completely sufficient for the use cases mentioned 
in <https://issues.guix.gnu.org/51427#1>, I don't think this can be 
considered a higher quality outcome, see above.

However, IMO having both <https://issues.guix.gnu.org/51427#1> and 
"--invalidate" would be even better; being able to test what happens if 
a non-registered directory exists in /gnu/store (e.g. a substitution 
interrupted by a sudden power-off) might be convenient for testing 
(without actually having to abruptly shut down the computer) the 
behaviour of a hypothetical GNUnet equivalent of "guix publish" 
(assuming that it works by doing a scandir of the store etc.).

Best regards,
Maxime Devos.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]