Op 12-06-2023 om 15:05 schreef Maxim Cournoyer: > Hi Maxime, > > Maxime Devos 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 >>> . >>> 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 >> 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 . > 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 __; 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 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 , I don't think this can be considered a higher quality outcome, see above. However, IMO having both 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.