Konstantin, please tell me what you're basing this on.
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
On the other hand, for the only incidences I can remotely refer to inthe past year and a half, there has been:
- the mm developer who started outright swearing at me on IRC in a
discussion about assertions
- 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.
- 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?
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.
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.
As a reminder, this all stems from a single patch, purely internal to
fs/bcachefs/, that was a critical, data integrity hotfix.
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.
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.