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

[Leo Prikler]

Hi Mark,

Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver:
> 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*.
I think you're nitpicking here.  If "good faith vs. bad faith" is not a
boolean value, I could also be acting without one or the other, but
clearly I either have evil intentions or I don't – there's no middle
ground.  Likewise, there's no middle ground on assuming evil
intentions, you either assume they exist or you don't.  Of course, we
could get into technicalities of how evil you assume my intentions to
be, but that's not going to help us here.

> 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.
Which one is the rational position now?  Not assuming evil intentions
or assuming them?

> 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.)
IIRC I already answered that question as one of the first things in
this thread (before it got renamed), so I don't want to repeat myself
at lengths here.

> 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.
I'm not sure what you're trying to say here, but if it's something
along the lines of "Raghav must not be trusted", I disagree.  They
themselves have stated, that they have since learned from their past
mistakes and the only reason this commit was even introduced at this
point was because one of their older commits did not receive careful
review.

> 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.
I don't know why your rehashing this at this point, we went over this
already.  Please refer to Raghav's messages at the time, they were
helpful in clearing up the matter.

Regards,
Leo