lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd55b2ee-c54a-4eca-9406-92302ca61011@ftml.net>
Date: Tue, 12 Aug 2025 00:04:53 +0300
From: Konstantin Shelekhin <k.shelekhin@...l.net>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: admin@...inas.su, linux-bcachefs@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 list-bcachefs@...lthompson.net, malte.schroeder@...ip.de,
 torvalds@...ux-foundation.org
Subject: Re: [GIT PULL] bcachefs changes for 6.17

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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ