all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: "Mark H Weaver" <mhw@netris.org>, 宋文武 <iyzsong@outlook.com>
Cc: Guix Devel <guix-devel@gnu.org>,
	GNU Guix maintainers <guix-maintainers@gnu.org>
Subject: Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)
Date: Sun, 02 May 2021 22:09:24 +0200	[thread overview]
Message-ID: <f5f8e17c091627981162cbff4c34d75f48dd6d22.camel@student.tugraz.at> (raw)
In-Reply-To: <87k0ohorww.fsf@netris.org>

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



  reply	other threads:[~2021-05-02 20:09 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22  0:58 A "cosmetic changes" commit that removes security fixes Raghav Gururajan
2021-04-22  2:41 ` Mark H Weaver
2021-04-22  3:17   ` Raghav Gururajan
2021-04-22  4:05     ` Raghav Gururajan
2021-04-22  4:33       ` Mark H Weaver
2021-04-22  5:02         ` Raghav Gururajan
2021-04-22 17:21       ` Mark H Weaver
2021-04-22 17:40         ` Another misleading commit log (was Re: A "cosmetic changes" commit that removes security fixes) Mark H Weaver
2021-04-22 20:06           ` Léo Le Bouter
2021-04-22 21:24             ` Ricardo Wurmus
2021-04-22 21:33             ` Mark H Weaver
2021-04-26 17:17               ` Ludovic Courtès
2021-04-28 16:43                 ` Criticisms of my "tone" " Mark H Weaver
2021-04-28 17:55                   ` Leo Famulari
2021-04-28 20:24                     ` Pjotr Prins
2021-04-29  6:54                       ` Joshua Branson
2021-04-29  9:26                   ` Léo Le Bouter
2021-04-29 15:30                     ` Matias Jose Seco Baccanelli
2021-04-30  0:57                   ` aviva
2021-05-01 17:02                   ` Giovanni Biscuolo
2021-05-01 20:07                     ` Leo Prikler
2021-05-01 22:12                       ` Mark H Weaver
2021-05-01 22:54                         ` Mark H Weaver
2021-05-01 23:15                         ` Leo Prikler
2021-05-02  3:13                           ` Mark H Weaver
2021-05-02 10:31                             ` Leo Prikler
2021-05-03  9:00                               ` Mark H Weaver
2021-05-03  9:59                                 ` Leo Prikler
2021-05-03 17:00                                   ` Mark H Weaver
2021-05-02  4:17                           ` 宋文武
2021-05-02  4:31                             ` Leo Famulari
2021-05-02  6:26                               ` 宋文武
2021-05-02 15:01                             ` Leo Prikler
2021-05-02 19:29                               ` Mark H Weaver
2021-05-02 20:09                                 ` Leo Prikler [this message]
2021-05-02 21:02                                   ` Mark H Weaver
2021-05-02 21:58                                     ` Leo Prikler
2021-05-02 20:59                                 ` Ludovic Courtès
2021-05-02 21:23                                   ` Mark H Weaver
     [not found]                           ` <87czu9sr9k.fsf@outlook.com>
2021-05-02  4:33                             ` 宋文武
2021-04-22 21:51             ` Another misleading commit log " Ludovic Courtès
2021-04-22 21:49         ` A "cosmetic changes" commit that removes security fixes Raghav Gururajan
2021-04-24  8:09           ` Mark H Weaver
2021-04-30  0:58             ` aviva
2021-04-22 18:37       ` Leo Famulari
2021-04-22 18:48         ` Mark H Weaver
2021-04-22 21:50         ` Raghav Gururajan
2021-04-22  4:08     ` Mark H Weaver
2021-04-22 11:39       ` 宋文武
2021-04-22 13:28         ` Mark H Weaver
2021-04-22 20:01       ` Léo Le Bouter
2021-04-22 21:08         ` Christopher Baines
2021-04-22 21:09         ` Leo Prikler
2021-04-22 21:21         ` Mark H Weaver
2021-04-23 17:52           ` Maxim Cournoyer
2021-04-23 18:00             ` Raghav Gururajan
2021-04-23 18:38               ` Maxim Cournoyer
2021-04-23 22:06                 ` Raghav Gururajan
2021-04-23 18:50             ` Léo Le Bouter
2021-04-23 19:15               ` Leo Prikler
2021-04-23 19:18               ` Leo Famulari
2021-04-23 19:33                 ` Léo Le Bouter
2021-04-23 20:12                   ` Leo Famulari
2021-04-26 17:06                     ` Giovanni Biscuolo
2021-04-26 17:32                       ` Leo Famulari
2021-04-26 21:56                         ` Giovanni Biscuolo
2021-04-26 23:01                           ` Leo Famulari
2021-04-24  7:46                   ` Mark H Weaver
2021-04-26 14:59                     ` Léo Le Bouter
2021-04-26 15:23                       ` Tobias Geerinckx-Rice
2021-04-26 17:21                         ` Ludovic Courtès
2021-04-26 20:07                           ` Pjotr Prins
2021-04-26 17:46                         ` Léo Le Bouter
2021-04-28 15:52                           ` Marius Bakke
2021-04-29  9:13                             ` Léo Le Bouter
2021-04-29 11:46                               ` Leo Prikler
2021-04-29 11:57                                 ` Léo Le Bouter
2021-04-29 11:41                             ` Arun Isaac
2021-04-29 12:44                               ` Pierre Neidhardt
2021-04-29 14:14                                 ` Pjotr Prins
2021-04-30 17:40                                   ` Pierre Neidhardt
2021-04-30 19:56                                     ` Pjotr Prins
2021-05-01  7:23                                       ` Arun Isaac
2021-05-01 12:40                                         ` Pjotr Prins
2021-05-01  9:15                                       ` Pierre Neidhardt
2021-05-01 10:18                                         ` Yasuaki Kudo
2021-05-03  7:18                                           ` Pierre Neidhardt
2021-05-01 14:50                                     ` Giovanni Biscuolo
2021-05-03  7:25                                       ` Pierre Neidhardt
2021-05-04  2:18                                         ` Bengt Richter
2021-05-04  6:55                                           ` Pierre Neidhardt
2021-05-04 15:43                                             ` Ludovic Courtès
2021-05-06 17:18                                               ` Pierre Neidhardt
2021-04-29 16:21                               ` Arun Isaac
2021-04-26 19:31                 ` Léo Le Bouter
2021-04-27 18:10                   ` Andreas Enge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f5f8e17c091627981162cbff4c34d75f48dd6d22.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@gnu.org \
    --cc=iyzsong@outlook.com \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.