public inbox for linux-bcachefs@vger.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Shelekhin <k.shelekhin@ftml.net>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: admin@aquinas.su, linux-bcachefs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	list-bcachefs@carlthompson.net, malte.schroeder@tnxip.de,
	torvalds@linux-foundation.org
Subject: Re: [GIT PULL] bcachefs changes for 6.17
Date: Tue, 12 Aug 2025 00:04:53 +0300	[thread overview]
Message-ID: <fd55b2ee-c54a-4eca-9406-92302ca61011@ftml.net> (raw)
In-Reply-To: <iktaz2phgjvhixpb5a226ebar7hq6elw6l4evcrkeu3wwm2vs7@fsdav6kbz4og>

On 11/08/2025 17:26, Kent Overstreet wrote:

> Konstantin, please tell me what you're basing this on.

This, for example: - 
https://lore.kernel.org/all/9db17620-4b93-4c01-b7f8-ecab83b12d0f@kernel.dk/ 
- 
https://lore.kernel.org/all/20250308155011.1742461-1-kent.overstreet@linux.dev/ 
I've just lurked around lore for a couple of minutes.

> The claims I've been hearing have simply lacked any kind of specifics;
if there's people I'd pissed off for no reason, I would've been happy to
apologize, but I'm not aware of the incidences you're claiming - not
within a year or more; I have made real efforts to tone things down.

Both links are four months old.

> On the other hand, for the only incidences I can remotely refer to in
the past year and a half, there has been:
>
> - the mm developer who started outright swearing at me on IRC in a
> discussion about assertions

That is very unfortunate.

> - the block layer developer who went on a four email rant where he,
> charitably, misread the spec or the patchset or both; all this over a
> patch to simply bring a warning in line with the actual NVME and SCSI
> specs.

My team has contributed to NVMe and SCSI subsystems, so I have some
experience working with Jens, Martin and Christoph. Nobody on my team
had this level of drama, even when we were in disagreement about specs
or intended behavior.

> - and reference to an incident at LSF, but the only noteworthy event
>  that I can recall at the last LSF (a year and a half ago) was where a
>  filesystem developer chased a Rust developer out of the community.
>
> So: what am I supposed to make of all this?

That you're trying to excuse your communication issues with other people's
communication issues?

> To an outsider, I don't think any of this looks like a reasonable or
> measured response, or professional behaviour. The problems with toxic
> behaviour have been around long before I was prominent, and they're
> still in evidence.

Again, "Timmy also did that" is not a very good excuse for a grown up adult.

> It is not reasonable or professional to jump from professional criticism
> of code and work to personal attacks: it is our job to be critical of
> our own and each other's code, and while that may bring up strong
> feelings when we feel our work is attacked, that does not mean that it
> is appropriate to lash out.

This is _NOT_ about the code. That's the essence of your struggles. Forget
about the code, the code is not the issue here. Communication is.

> As a reminder, this all stems from a single patch, purely internal to
> fs/bcachefs/, that was a critical, data integrity hotfix.

But this does not matter. No matter how important your fix is.

> There has been a real pattern of hyper reactive, dramatic responses to
> bugfixes in the bcachefs pull requests, all the way up to full blown
> repeated threats of removing it from the kernel, and it's been toxic.

Play stupid games, win stupid prizes. Piss off a maintainer long enough,
he will refuse to work with you. Who would've thought, eh?

> And it's happening again, complete with full blown rants right off the
> bat in the private maintainer thread about not trusting my work (and I
> have provided data and comparisons with btrfs specifically to rebut
> that), all the way to "everyone hates you and you need therapy". That is
> not reasonable or constructive.

You seem to ignore what people keep telling you: _COMMUNICATION_ is the
problem, not the _CODE_. So arguments about how btrfs performs compared
to bcachefs do not matter.

Your result is not the issue, the journey with you is.


  parent reply	other threads:[~2025-08-11 21:05 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-28 15:14 [GIT PULL] bcachefs changes for 6.17 Kent Overstreet
2025-08-05 21:19 ` Malte Schröder
2025-08-05 22:41   ` Carl E. Thompson
2025-08-07 12:42     ` Aquinas Admin
2025-08-09 17:36       ` Kent Overstreet
2025-08-09 19:21         ` Josef Bacik
2025-08-09 20:37           ` Kent Overstreet
2025-08-09 21:34             ` Kent Overstreet
2025-08-10  2:24             ` Theodore Ts'o
2025-08-10  3:17               ` Kent Overstreet
2025-08-10  4:05                 ` Sasha Levin
2025-08-10  4:13                   ` Kent Overstreet
2025-08-10  4:26                     ` Gerald B. Cox
2025-08-10  5:17                       ` Kent Overstreet
2025-08-10  5:59                       ` Theodore Ts'o
2025-08-10  6:51                         ` Kent Overstreet
2025-08-10 10:22                         ` Martin Steigerwald
2025-08-11 15:48                         ` Peanut gallery 2c James Lawrence
2025-08-11 16:08                           ` Kent Overstreet
2025-08-11 17:00                             ` James Lawrence
     [not found]                             ` <aJsIOj6jbPKayO0s@mayhem.fritz.box>
2025-08-12 16:26                               ` Kent Overstreet
2025-08-11 16:48                   ` [GIT PULL] bcachefs changes for 6.17 Aquinas Admin
2025-08-10  8:02                 ` Martin Steigerwald
2025-08-10  6:05               ` Carl E. Thompson
2025-08-11 16:02           ` Aquinas Admin
2025-08-11 16:09             ` Kent Overstreet
2025-08-09 23:01         ` Matthew Wilcox
2025-08-09 23:13           ` Kent Overstreet
2025-08-12  7:49             ` Jani Partanen
2025-08-12 10:09               ` Martin Steigerwald
2025-08-11  9:51         ` Konstantin Shelekhin
2025-08-11 14:26           ` Kent Overstreet
2025-08-11 18:13             ` Carl E. Thompson
2025-08-11 18:40               ` Malte Schröder
2025-08-12  0:44                 ` Carl E. Thompson
2025-08-11 18:48               ` Aquinas Admin
2025-08-11 19:42               ` Martin Steigerwald
2025-08-11 21:04             ` Konstantin Shelekhin [this message]
2025-08-12  1:08               ` Kent Overstreet
2025-08-12  6:52             ` asdx
2025-08-12  7:04               ` Kent Overstreet
2025-08-12  7:17                 ` asdx
2025-08-12 19:35             ` Keith Busch
2025-08-12 20:03               ` Kent Overstreet
2025-08-12 20:30                 ` Keith Busch
2025-08-12 20:31                   ` Kent Overstreet
2025-08-12 20:38                     ` Keith Busch
2025-08-12 20:45                       ` Kent Overstreet
2025-08-12 20:54                         ` Keith Busch
2025-08-12 20:57                           ` Kent Overstreet
2025-08-11 16:45           ` Aquinas Admin
2025-08-10  4:29       ` Gerhard Wiesinger
2025-08-07 14:27   ` Martin Steigerwald
2025-08-07 17:29   ` Peter Schneider
2025-08-10  6:20 ` Gerhard Wiesinger
2025-08-10 10:32   ` Martin Steigerwald

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=fd55b2ee-c54a-4eca-9406-92302ca61011@ftml.net \
    --to=k.shelekhin@ftml.net \
    --cc=admin@aquinas.su \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=list-bcachefs@carlthompson.net \
    --cc=malte.schroeder@tnxip.de \
    --cc=torvalds@linux-foundation.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox