Linus Torvalds Comments On Bcachefs Prospects For Linux 6.6

[dragorth]

Honestly, this is giving me Tux3 vibes all over again. At some point we are going to have to say the reason we don't get new FS in the kernel is the kernel team and not the teams trying to jump through the hoops that are placed in front of them.

[RahulSundaram]

Honestly, this is giving me Tux3 vibes all over again. At some point we are going to have to say the reason we don't get new FS in the kernel is the kernel team and not the teams trying to jump through the hoops that are placed in front of them.

Plenty of other filesystems have been routinely merged in the kernel after Tux3 however and the barrier to having something as large and long term impact as a filesystem should be quite high. Arguably, the kernel has the opposite problem. Too many filesystems including Btrfs and Ntfs have gotten merged prematurely and kernel developers have regretted this before. If they are reacting now by pushing harder to get issues resolved upfront, that's a good thing. Other than technical reviews which seem largely in favor in this case, having cooperative maintainers who are willing to follow the process and work with other subsystem maintainers is also critical. When that fails, features do get rejected routinely, refer to CML2 (kernel build system), CK patch set (scheduler), Reiserfs4 (filesystem) etc. Hopefully that doesn't happen here.

[pWe00Iri3e7Z9lHOX2Qx]

He's busy burning all the good will because he cannot wait three months? Really amazing. He're the thread from the last (6.5) release cycle he got this earnest feedback from the VFS maintainer:

I feel like painting this as entirely one sided from Kent is disingenuous. Let's face it, there's an overabundance of assholery on LKML. They need more maintainers across the board, but it's an inhospitable place. I get some pot calling the kettle black vibes in these mailing list threads.

[Quackdoc]

I didnt even click with me that it wasnt going into linux-next lmao

[fitzie]

I feel like painting this as entirely one sided from Ken is disingenuous. Let's face it, there's an overabundance of assholery on LKML. They need more maintainers across the board, but it's an inhospitable place. I get some pot calling the kettle black vibes in these mailing list threads.

I agree. I'm a big fan of Kent, I've watch him deliver talks and seems pretty laid back fellow. I'm also a long term patreon donator to bcachefs and I want it to succeed. But these events are entirely predicable based on how he reacts. After the last attempt to submit, there was clearly no action taken by Kent to ensure this release was going to go well. There was no call for testers on the bcachefs mailing list, no attempts to address anything but the bare minimum what he sees as the barriers for submission to the kernel.

Linus again called him out for not playing well. Kent responded to similar criticism in the past to the effect that they all deserved it. Even if that is true, how is that productive? Kent has these beefs and he's very disrespectful to other developers. Go look at the io_uring thread, where Kent starts chastising developers who bothered to look into a bug report Kent made. From https://lore.kernel.org/lkml/2023063...0aaa@brauner/:

>
> Maybe if you had told someone about that it could get looked at?

I'm more likely to report bugs to people who have a history of being
responsive...

> Look, the main thing I want to say is - I'm not at all impressed by this
> continual evasiveness from you and Jens. It's a bug, it needs to be
> fixed.
>
> We are engineers. It is our literal job to do the hard work and solve
> the hard problems, and leave behind a system more robust and more
> reliable for the people who come after us to use.
>
> Not to kick the can down the line and leave lurking landmines in the
> form of "oh you just have to work around this like x..."

Jens posted a fix that didn't actually fix anything, and after that it
seemed neither of you were interested in actually fixing this. So based
on that, maybe we need to consider switching fstests back to AIO just so
we can get work done...

What would be best is if Kent said, "I'll pull this for this rc, and submit to linux-next" for the next release, and really to follow up on the rwsem/sixlocks and iomap/bcachefs way of doing things now. Show the kernel community that he wants to improve things and not just show off how he's smarter then the rest of them. And he would also show them that he's able to move beyond whatever transgressions have occurred in the past. Then people will be happy to ACK bcachefs for 6.7, and they will be happy that there's a plan to improve rwsem/iomap, and they will be happy that Kent is able to turn the other cheek.

[blackiwid]

I think that is a burocracy thing, processes with multiple people are poison to developers.

Why is sending directly to Linus a problem, it can only be a problem if there is already a divide before he sends it. Why do this people take this personally and are they not strictly professional?

Now sure you can get problems if you skip a level of boss in a company, yet he is not inside the "company" yet so he is more like a outside contractor at this point. But again if they all would be great outside they would not have to worry that a attempt to go besides them would result in anything bad, either a integration would be bad then Linus should not even consider it and there would not be a worry, or he can do that, and it's a semi-official way to get things done, then he did nothing wrong anyway.

It seems like a mixture of them not having clearly defined structure or rules or different preferences and also it's like what a huge group where he is the outsider and he is easily singled out if he not kisses their feet at every step and lies on the back and shows his neck...

Sure that is partially speculation but if there is a ingroup and 1 outsider that is always unhealthy towards the 1 in my experience, except he can change the group dynamic to his favor.

Also I think the Kernel Team should be more or less like a service to integrate stuff, if you have not the manpower than somewhere the way scaling failed maybe this many millions funding the Linux Foundation gained does not go enough % to such jobs. And yes you can't short term solve everything with money but mid term you very well can.

You can't just have 1 standard for everything, if it's something that would be great for linux it should be have lesser rules than if it's just meh and only few people care about it.

It should not be like entering a political party and make coffee for 5 years till you get voted for. He could be hit by a bus in 6 Months, so what is different that some people get mad at him and worst case they ban him? Both cases they need to replace him or remove the code. It seems there is no extremely toxic behavior otherwise somebody would have the comments with insults posted here, right? So it seems a lot of nitpicking.

Why did nobody make him or "ordered" him to add it to linux-next when it was clear that it's supposed to be merged in the next months 3-6 months ago?

[justinkb]

I 100% get where he's coming from with that bug report not being handled, though. I've dealt with that myself many times. There's nothing more annoying

[ElectricPrism]

From reading this thread the things I am picking up on are:

Victim complex. (Whether warranted or not in the context of their life and social connections.)

Behavioral problems/disorder. (Becoming easily irate)

Attitude problems -- "competition" vs "cooperation" -- how does he view the maintainers? As competition or collaborators?

--

On the other side of the fence -- yes any entity has a level of bureaucracy as pointed out in this thread, and internal politics (whatever shape and whatever extent that takes).

Burnout of maintainers -- maintainers are just people and people in general have been going through a lot these last few months. If there are human element setbacks, take it on the chin. Human resources are not unlimited.

Linus not appreciating the starting of a cluster-fsck on his lawn. Does he really need the extra drama and to divide his house? Sounds like some microsoft conspiring bs if that's who benefits.

--

From the article:

"But Torvalds has now chimed in and pointed out an immediate blocker that the pull request isn't making use of a signed Git tag with a PGP key with a chain of trust."

Sounds like defaulting to practical wisdom and choosing criticism wisely. I 100% agree -- having a PGP paper-trail is just such common sense nowadays. Your name goes on your code and reflects on you.

--

Final thoughts, if I didn't know any better I would describe this scenario similar to teenage angst. There are appropriate ways to process and deal with the general frustrations each of us feel every day from the social issues trying to work with others -- go ride a bike, run a marathon, lift weights, get laid / whatever. Most people prefer to have clear divisions between their personal life and their work life and as such ~~omit~~ sanitize conversations, feelings, and communications in the interest of pursuing more functional relationships with others. They seek common communication & common goals.

I'm sure the guy is brilliant, people who show great capability and encounter these problems often times are.

I feel sympathetic for him like others in this thread because our community commonly has sympathy for "the underdog", but in this scenario, he needs to stop seeing himself as the victim, stop sewing divison and drama, grow up, acknowledge the hierarchy, and try to cooperate with the maintainers. Communicate, communicate, communicate.

And the maintainers should try to treat newcomers consistently, fairly and without malice. Anybody would be frustrated to have different standards at different times or for different people -- and it sounds like from the thread that various filesystems had different levels of push-back and hoops.

I've known people with aspergers who lack this "strategic empathy" to be able to guess how their actions will make others feel or react, and it feels similar to what may be happening.

Everybody needs to focus on the work and remember they are a team. Some people in the middle of the team and others on the outskirts of the team helping in their own way.

Unity is the only functional path forward, they should all focus on the work and show patience and try to keep communications limited to higher-level brain functions.

[oiaohm]

I think that is a burocracy thing, processes with multiple people are poison to developers.

Why is sending directly to Linus Torvard a problem, it can only be a problem if there is already a divide before he sends it.

Sometimes there is a good reason for bureaucracy.

There is a good question the. Why sending it directly to Linus branch a problem and answer is simple and it does not agree with what you wrote.

https://bottest.wiki.kernel.org/

There are a stack of automated bots that code quality check every submit to Linux-next branch as well as the Linus kernel branch. Yes so non human machines can spot and report stack of issues to be fixed without costing any of Linus time.

Please also note submit to the next branch is submitting to "Stephen Rothwell".

The next answer by Linux Torvalds

"As it is, I'm not convinced I want to even continue to go through this all, when it fails at the very first hurdle. A clean build is not some "would be nice" feature, and it is big part of why we have automation for new code."

Notice the automation for new code this is the bots that automatically check the new code, Yes if your code goes correctly by linux-next then to linus branch the result is before Linux Tovarld sees the code the defects automation tests can find have already been removed.

Why did nobody make him or "ordered" him to add it to linux-next when it was clear that it's supposed to be merged in the next months 3-6 months ago?

That is answered by Linus post.

The fact that I only now notice that you never submitted this to linux-next is obviously on me. My bad.

Linus Torvalds was in fact meant to check that it has been submitted to linux-next before accepting the code or even started talking about it. Linus Torvalds made a error it does happen.. Linus Torvalds should have given that order 3-6 months ago.

Another thing to remember bcache not bcachefs the bit that already mainline Linus Torvalds back when bcache was mainlined Kent Overstreet was also told new code had to enter by Linux-next branch and that he had to submit it to Stephen Rothwell the lead developer of Linux-next. So this does fall on Kent Overstreet as well for forgetting the process Linus Torvalds had told him to use in the past. Ok I am willing to give Kent Overstreet the benefit time causing human to forgot here that we are talking years ago.

Now you could say issue with Linux kernel documentation here as well.

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Select the recipients for your patch You should always copy the appropriate subsystem maintainer(s) and list(s) on any patch to code that they maintain; look through the MAINTAINERS file and the source code revision history to see who those maintainers are. The script scripts/get_maintainer.pl can be very useful at this step (pass paths to your patches as arguments to scripts/get_maintainer.pl). If you cannot find a maintainer for the subsystem you are working on, Andrew Morton (a[email protected]) serves as a maintainer of last resort.

[email protected] should be used by default for all patches, but the volume on that list has caused a number of developers to tune it out. Please do not spam unrelated lists and unrelated people, though.

Many kernel-related lists are hosted on vger.kernel.org; you can find a list of them at http://vger.kernel.org/vger-lists.html. There are kernel-related lists hosted elsewhere as well, though.

Do not send more than 15 patches at once to the vger mailing lists!!!

Linus Torvalds is the final arbiter of all changes accepted into the Linux kernel. His e-mail address is <[email protected]>. He gets a lot of e-mail, and, at this point, very few patches go through Linus directly, so typically you should do your best to -avoid- sending him e-mail.

Yes the documentation does not direction mention the must submit to Linux-next. But going to subsystem maintainer first as the documentation directs when you get past the subsystem maintainer the patches then go into Linux-next branch as part of the process. Like it or not sending to Linus Torvalds without a subsystem maintainers signature is wrong. Yes due to Linus Torvalds workload the documentation is clearly recommend do not bother Linus Torvalds directly.

Now if there is a dispute between your patch and what the subsystem maintainer your patch owns to classes as acceptable then its bother Linus Torvalds but I cannot find this with bcachefs.

I do think this section of Linux documentation should contain a note saying subsystem Maintainers will submit code to Linux-next before their code goes to Linus tree.

Bcachefs does not have the sign-off by Stephen Rothwell and the automated bots on the Linux-next branch like it or not this is a problem.

Like it or not this Linux kernel bureaucracy is important to code quality control. Going straight to Linus if the code gets in there could be quality control problems.

Remember in the rare cases today that Linus Torvalds decide to write a patch himself other than just changing the release number/name you see Linus Torvalds submit that patch to the correct maintainer and it then go past Stephen Rothwell in the Linux-next branch before Linus Torvalds signs it again. So Linus here is not asking Kent Overstreet to do something he himself does not do. Linus Torvalds does not put himself above the Linux kernel peer review process.

[mlau]

I feel like painting this as entirely one sided from Kent is disingenuous. Let's face it, there's an overabundance of assholery on LKML. They need more maintainers across the board, but it's an inhospitable place. I get some pot calling the kettle black vibes in these mailing list threads.

I've been reading and posting to lkml for over 15 years now, and the most "assholery" as you put is initiated by people from the outside, like Kent. When I read his response to Waiman Long that the overlap of rwlocks and his new sixlocks won't fly my first thought was "goodbye, a**hole". It's this typical "I'm much smarter than you, be grateful that I even considered donating this code to you, so shut up and take it"-attitute that turns maintainers off, especially when it's not just one but many Kents you have to deal with. Ignoring the maintainers and going straight to
the last hurdle (Linus) for merging is just more of the same attitude.

You are correct that more reviewers are required, but behavior like Kents' is turning them away too. He wants this merged, so he needs to be patient, and try to also cut the overworked maintainers/reviewers some slack. Antagonizing them because you think you're smarter won't do him any favors.

20 years ago, Al Viro (the initial vfs Maintainer) summed up what being a maintainer is about:

Date: Tue, 18 May 2004 21:00:07 +0100
From: Al Viro
User-Agent: Mutt/1.4.1i
To: Mark Gross
Cc: Christoph Hellwig, Tim Bird, linux kernel
Subject: Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

On Tue, May 18, 2004 at 12:32:48PM -0700, Mark Gross wrote:
> These are some of the types of problems engineers at REAL software shops have
> to solve to be able to ship REAL product for REAL money. If you haven't HAD
> to produce code like this yourself at some point in your carrier then you've
> lived a sheltered life.
>
> Its disingenuous for you to get on your ivory tower to point and laugh.

Well, you see, after spending years cleaning up the excrements
of self-styled "REAL engineers" it's either get on the tower to point and
laugh or get on the tower to point and shoot.