Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Mark H Weaver <mhw@netris.org>]

Hi Leo,

Leo Prikler <leo.prikler@student.tugraz.at> writes:

> Let us assume for
> the sake of argument I were to introduce a bug into Guix.  There are a
> number of ways this can happen, but let's focus on the important
> distinction here, which is me purposefully introducing that bug vs. it
> happening due to oversight.
>
> Let us imagine the following four scenarios:
> 1. You assume I'm acting in bad faith and I indeed am.
> 2. You assume I'm acting in bad faith and I am not.
> 3. You assume I'm acting in good faith and I am not.
> 4. You assume I'm acting in good faith and I am.

This is a false dilemma <https://en.wikipedia.org/wiki/False_dilemma>,
because you've missed a very important case, namely:

5. You assume *nothing*.

This is, in fact, the current scenario.  I'm not making any assumptions.
That is truly the state of my mind on this question, and I think it's
the only rational position to take.

In particular, I don't feel the need to introduce assumptions in order
to justify my question in the opening email of this thread, namely
whether someone who pushed a "cosmetic changes" commit that removes
security fixes should have commit access.

That question does _not_ imply that anyone acted in bad faith.  From my
perspective, it doesn't matter for our purposes.  (Of course, it would
be good to know, but I'd rather not be distracted by questions that we
have little hope of ever answering.)

My primary concern here is to protect our users, and the integrity of
our systems and of Guix itself.  I don't know how to do that if we
tolerate committers who repeatedly push commits with misleading commit
messages.

In order for meaningful oversight of Guix to be practical, it is of
*paramount* importance that the summary lines of commits be reasonably
accurate.  I have neither the time nor the interest in scrutinizing
_every_ commit pushed to our repository, just in case the summary lines
are misleading.  Therefore, I claim that we *must not* tolerate
committers who repeatedly push commits with misleading commit logs.

We are lucky that this incident was discovered.  There's no guarantee
that the next one will be.

This is _not_ about being a beginner.  No technical expertise should
have been required to avoid this incident, only some basic care before
pushing commits.  Even the most cursory glance at the commit log should
have immediately raised red flags, because its summary line clearly
contradicts the next few lines of the commit log itself:

--8<---------------cut here---------------start------------->8---
gnu: cairo: Make some cosmetic changes.

* gnu/packages/patches/cairo-CVE-2018-19876.patch,
gnu/packages/patches/cairo-CVE-2020-35492.patch: Remove patches.
* gnu/local.mk (dist_patch_DATA): Unregister them.
* gnu/packages/gtk.scm (cairo): Make some cosmetic changes.
[replacement]: Remove.
(cairo/fixed): Remove.
--8<---------------cut here---------------end--------------->8---

I don't know what went wrong here, but it doesn't really matter to me.
Whatever the reason, I don't want someone who pushes commits like this
to have commit access.  If people want to condemn me for saying that,
so be it.

     Regards,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.