Re: A "cosmetic changes" commit that removes security fixes

["Léo Le Bouter" <lle-bout@zaclys.net>]

[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]

On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote:
> I have to agree with everybody in this thead.
> 
> The commits in question were problematic (especially on core-updates,
> which is not a "WIP" branch and thus cannot be rewritten to fix past
> problems). I'm not confident that the security fixes would have been
> reinstated on core-updates if Mark had not asked about them.
> 
> Léo and Raghav, you need to keep learning our workflow around
> security
> updates.  It's not okay to remove security patches and later update a
> package to a fixed version in a different commit. `git rebase` is the
> tool to learn for cases like this one.

I do not think here that Raghav and myself should somehow be framed as
people having to learn more and that would be the reason for these
issues. To talk about myself, I think the main difference here is that
Mark and myself consider different things to have value when
contributing to GNU Guix. Mark tends to consider the technicality of
contributing to GNU Guix, that the code be well tested, that every
change be made in a very rigorous way. I tend to also consider these
things but also consider other things like how people feel when they
contribute to GNU Guix, do they feel discouraged or rewarded by their
contributions, I find that it can be tiring and very discouraging to
respond back and forth to many many review comments, and at some point,
even if things have some rough edges, I tend to prefer rewarding a
contributor for their work than insist the commit history should be
perfect or something. I also stopped upholding myself to high rigorous
standards at all times, also because I think it is not good for my
mental health. I tend to move the responsability of rigorous testing
into tools, I think putting testing/checking into tools is at the same
time good for mental health and inclusive because it means also
everyone can check their own changes and correct errors. Having tools
to check things is less stressful for everyone, I discovered that
aspect after I learned Rust and I think it really is the way to go. I
think there is an aspect of contribution where people feel stressed and
doubt themselves and that's what keeps them away from contribution, if
we have tools then those problems tend to disappear because the tool
acts as a stopgap, the tool can also be collectively improved as soon
as more best practices are discovered by the community. Rust does this
with clippy lint rules, the borrow checker and the very well made
error/warning reporting of the compiler. I think relying more on tools
even if we never can do so fully and less on individual accountability
is better here.

> 
> However, Mark, you have way more experience, and you need to handle
> these things differently. If you don't trust certain Guix
> contributors,
> take it up with the maintainers — in private. The style of
> communication
> you used here is ineffective and will dissuade people from
> contributing
> to Guix. Do you want Léo and Raghav to learn and improve? Or do you
> want
> them to leave? Remember that we all begin as beginners.

Léo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]