Linus is fed up with the #bcachefs pull requests from Kent:
"'The bcachefs patches have become these kinds of "lots of development during the release cycles rather than before it", to the point where I'm starting to regret merging bcachefs.
If bcachefs can't work sanely within the normal upstream kernel release schedule, maybe it shouldn't *be* in the normal upstream kernel.
This is getting beyond ridiculous.
Linus'"
https://lore.kernel.org/all/CAHk-%3Dwj1Oo9-g-yuwWuHQZU8v%3DVAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com/ #Linux #LinuxKernel #kernel
@kernellogger That whole subthread is basically Kent Overstreet throwing a temper tantrum together with a megalomaniac episode. What the heck is wrong with waiting for the next merge cycle to do things according to process? At this point, I'd be avoiding using any of bcachefs until another person who is not Kent takes over the management of that subproject. Carl says it well https://lore.kernel.org/all/1816164937.417.1724473375169@mail.carlthompson.net/
@kernellogger The first reply underlines Linus' concerns; completely missing the point and having the wrong attitude. Not the way to work towards a healthy relationship & following proper process like anybody else:
"But I've got to get this done, and right now that does mean moving fast
and grinding through a lot of issues.β
@kernellogger Reminds me of https://lore.kernel.org/all/8734t0vntp.fsf@intel.com/
I'm all for doing cleanups and stuff, but it's not cool to merge patches behind the maintainers' backs through your own trees. It's not free for all, never has been, no matter how trivial the patches.
@kernellogger Oh funny, the same guy who did not understand why people might need Debian stable.
well, not totally sure, but that might be unfair, as Kent claimed he was taking about _unstable_ (I did not look that closely, but I thought I mention it)
https://lore.kernel.org/all/qri2e26cmkjmffya27mx5g2yuasswlbw4opnzokpybnvt2t5et@wvjj3o3lj4qc/
@jani ohh, yeah, I remember.
Corporating in a big project and sticking to its rules sometimes is annoying and time-consuming, but in the end it really is worth it.
Not to mention that Kent here violated something that in a ideal world (e.g. not the one we live in) might not even need a written rule, as it should be obvious to anyoneβ¦
@jlin @kernellogger yeah I'm sitting on some locking fixes because bcachefs has some very funny ideas how console_lock and printk work. but I don't want to deal with this mess, so I guess as long as syzcaller has bcachefs enabled we'll just get a bunch of lockdep splats all over in other places
@sima @jlin @kernellogger Wait what? Why would bcachefs have anything to do with console lock?
@sima @jlin @kernellogger talking about lockdep and console lock and printk: it would be neat if there was a nice way to, while the system is booting, inform lockdep about lock nestings that are intentional but rarely observed, so that you can immediately get a lockdep warning when the intended locking order is violated...
@rostedt @kernellogger I had the same thought but did not dare go there.
@vbabka @jlin @kernellogger @jann yeah we do that all over for drm related locks. it also helps to make sure drivers all agree on the same lock order across platforms. we do ifdef the code out if lockdep is disabled
@kernellogger if it's going to be out of tree, I may as well use zfs as my filesystem again instead
well, we are not yet really at the point where Linus throws bcachefs out afaics.
And even if that happens, my first thought to your toot was:
Yes, I can understand that β but at the same time it's more complicated that that; for example, one of those filesystems is made for Linux and interacts nicely with the vfs and mm, while its way more complicated for the other. It might be naive, but that would scare me a little.
@kernellogger I don't know what I'm doing. I shouldn't be trusted to manage my own data.
I guess that holds true for most of us (me included) π¬ π₯΄ π
2/ Kent meanwhile send a smaller #bcachefs merge request[1] with just fixes for #Linux 6.11-rc, which Linus just merged[2] with minor complains about one of the changes[3].
FWIW, the one Linus refused to merge had "39 files changed, 1309 insertions(+), 671 deletions(-)", the new PR just merged had "25 files changed, 387 insertions(+), 192 deletions(-)"
[1] https://lore.kernel.org/all/awwxatomvqsjf3uao64qm3b4jq34tvdfpobe22wouydgzc534j@c6h7l4k7447c/
[2] https://git.kernel.org/linus/72bea05cb1ad486b1a850f584cc93b651579ad2f
[3] https://lore.kernel.org/all/CAHk-=wh3eEa-X6wAXpVLrh+i5a3dK0atBDPUf_XhFmhs7pKwZA@mail.gmail.com/
@kernellogger That VFS patch has never been on any mailing list and has never been seen by Al, Jan, or myself...
@ljs @vbabka @kernellogger I see it's #mm's turn to have fun.
@ljs @kernellogger @brauner i thought the point of maintainers is to make us feel small in the vast universe of chaos
@ljs @kernellogger @brauner oh no what did he do to btrfs
@ljs @kernellogger @brauner @lkundrak oh boy. in my experience btrfs has been pretty good, I've been using it on ubuntu as the fs on top of a raid5, using it for backups of other systems, Mac Time Machine over samba, and rsnapshot for some other linux systems. Compression enabled. No problems for 3 years I've been using it.
@vbabka @kernellogger @brauner @lkundrak @ljs The funny one about PF_MEMALLOC_NORECLAIM?
@vbabka @kernellogger @brauner @lkundrak @ljs See funny, meaning 2 in https://en.wiktionary.org/wiki/funny:
Strange or unusual, often implying unpleasant.
@kernellogger @brauner @vbabka @ptesarik @ljs is this gentleman also going to the vienna conference?
i'm bringing the π bong βοΈ π« π§