From: Leo Prikler <leo.prikler@student.tugraz.at>
To: 宋文武 <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 17:01:33 +0200 [thread overview]
Message-ID: <8df20a7d869d5bdca47aaf044ac9b229b020aea2.camel@student.tugraz.at> (raw)
In-Reply-To: <OSZP286MB0664663B45B37C217690DB5AA35C9@OSZP286MB0664.JPNP286.PROD.OUTLOOK.COM>
Am Sonntag, den 02.05.2021, 12:17 +0800 schrieb 宋文武:
> Hello Leo, I see nothing wrong for assuming bad faith when security
> fixes of packages are removed, in the end the truth matter, which I
> believe is: You thought the patches for cario is not needed now on
> core-updates, so you remove them.
> what I mean is "for assuming bad intent", or more clearly: "for
> assuming that you remove thoese security patches to introduce
> backdoors on purpose". I don't think Mark try to prove you're lying
> from his messages, if that's what "assumed bad faith" means...
Now, lfam has already pointed out, that I'm not Léo, but I don't think
whether I am or am not matters much in this context. 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.
In scenarios 1 and 4, your judgement is completely correct and we need
not further discuss it. But what about 2 and 3?
First, let's believe myself to be acting in bad faith while I am not.
You will attack me for introducing a bug into Guix and (because you've
already determined I'm acting in bad faith) strip me from commit
rights. This can either be the end of the story or the start of a long
rant started by me on how unfairly I was treated by Guix. Bad optics.
Now let's say you assume I'm acting in good faith while I am not. You
might want to (politely) ask me to come up with an explanation as to
why I introduced this bug. I might respond or not. Depending on my
response, you might even be fooled into believing I acted in good faith
until I conveniently introduce another bug. At some point, you will
probably have to conclude, that I'm not. In this scenario, I am kept
around longer than necessary and my repeated introduction of bugs
produces headaches to everyone, particularly when I circumvent the
review process.
To be honest, the way I presented 3, it looks very grim, but
realistically speaking, I don't think all of the maintainers will be
fooled for very long. With regards to the recent issue, we have a
clear account from Raghav as to what happened as well as their
statement, that they have since learned to be less misleading in their
commit messages. I often collaborate with Raghav or review their
patches and when doing so I can feel clear commitment from their side,
but also a sense of eagerness, that at times I feel uneasy about.
Rather than worrying, that they might intentionally do bad, I fear they
might do bad out of haste and I'm still in the process of learning how
to best communicate that to them. They are awfully fast at churning
out patch sets and at times I find myself outpaced, especially
recently, when Guix has not been the only project I'm working on.
Writing long essays by email also takes precious time away from patch
review, working on my own contributions or leisure. In short, I'm
slowly starting to feel a little too stressed.
But enough about my complaints. Long story short, I think we ought to
assume good faith when engaging in criticism, so as to not discourage
people, who otherwise do good work.
Regards,
Leo
next prev parent reply other threads:[~2021-05-02 15:11 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 [this message]
2021-05-02 19:29 ` Mark H Weaver
2021-05-02 20:09 ` Leo Prikler
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8df20a7d869d5bdca47aaf044ac9b229b020aea2.camel@student.tugraz.at \
--to=leo.prikler@student.tugraz.at \
--cc=guix-devel@gnu.org \
--cc=guix-maintainers@gnu.org \
--cc=iyzsong@outlook.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).