Linus Torvalds Comments On Bcachefs Prospects For Linux 6.6

[timofonic]

Kent is doing the right thing. He is strategically puting a stick into the ant nest. Letting them bleed out one by one. In the end his efforts will work out. The biggest talents will always get the most backlash, by those who feel threatened. BcacheFS will be a new era and thus some controversy is needed to cement its position.

Are you really sure? I tought a bit similar like you, but now I think differently.

I think controversy is a double edged sword. It may benefit in certain conditions, but it might destroy too. Also, personal discussions aren't good in LKML. I think he needs to become a lot more polite, get code merged and collaborate with developers, then get sponsors to be full time and hire at least dozen of developers for Bcachefs development.

He should direct to VFS maintainers and such. If they ignore him, that's another topic but talking directly to Linus might make a bad climate.

If the maintainer is an *hole, don't become another. Maybe there should be a mechanism to replace maintainers that become irresponsible, stupid, rude and other negative attitudes bad for Linux kernel development.

Linux kernel development ecosystem needs to be improved. I consider relying on a mailing list is a limitation, instead a GitHub/GitLab system but I consider that functionality should be implemented in Git itself with both web and native frontends.

I consider there needs to be some kind of "social training" to make teamwork better. Proper text-based communication is possible, but requires to develop certain skills not quite common to most people.

Kent isn't the only *hole here, but the most prominent because he wants his code to get merged. He should improve his social skills, his technological ones are already quite extremely high. Even Linus Torvalds improved over time, despite his rebuttals were quite funny but not constructive in the long term (Nvidia deserved the middle finger and still does, anyway).

I see Bcachefs development to be quite endangered until all involved parties reflect on it, accepting responsibilities and faults of themselves. Then learn from it and be sure all this crap doesn't happen again. And of course, more strict moderation and a better project governance model.

[oiaohm]

Well, in that case, and assuming this is not some overcomplicated plan to make an excuse to drop bcachefs from Kent's side, all this may be just misunderstanding.

Kent is not trying to merge bcachefs, he tries to merge prerequisite, a new sync primitive to kernel. He may not realize this is a feature which should come through linux-next, more like bugfix. I assume he've merged some patches to bcache with some kind of shortcut process.

From what I've read during previous attempts, it was like: "Please, review my code... Anybody?". I don't know, maybe it was done via some private channel. Up to last month I was sure, nobody in kernel team wants to touch bcachefs, when suddenly Linus himself had mentioned it within notes to one of RCs. Then he himself reviewed code, all this looked like Linux himself is eager to merge this asap. And now he turns 180 degrees and say like "go away and never turn back. Nobody likes you here anyway".

I would class it as error in process. As maintainer of bcache Kent is allowed to short cut the process to a point. Yes a maintainer he can submit directly to the next tree.

There is a problem here. When you go though the Linux kernel documentation you find something.
"Andrew Morton serves as a maintainer of last resort."

You cannot find some maintainer to review your patch then you are meant to raise the issue with "Andrew Morton" who will either get some maintainer to review the code or review it himself. Now what you are working on you want into the Linux kernel but its not quite ready for users "Greg Kroah-Hartman" of the staging branch is for you.

As I said the documentation on this stuff is not clear enough. He did not place a "merge request" with either "Greg Kroah-Hartman" or "Andrew Morton" or Next branch or any other maintainer.

Please remember asking people to review your code that is asking humans to review you code. Put your code in the next branch asks the automated tools to review your code.

Linus could never do a final merge into head of kernel without having the signed of the automated tools as you get going though the next branch..

Khrundel yes i know how it appears but you have to remember Kent is a Linux kernel maintainer he should be following the kernel maintainers guidelines that include putting the code in the next tree by some means before bring the issue up with Linus. Yes with the fault that Linus is finding Kent would have submitted this code to the next tree and the automated reviews would have been no your code is not good enough please fix this and try again. So its understandable Linus is a bit annoyed he just worked out due to Kent not following correctly process he been wasting his time reviewing code and sending responses that he should not have been reviewing.

Patches moving though the Linux kernel trees in the correct way is party to make your Linux kernel master branch maintainers like Linus Torvalds and LTS maintainers don't get over worked and burnt out.

Think about it if every person who wants to submit code follows what Kent does how long until Linus himself is totally overloaded and burnout. So Kent seeing possible a simple solution has made a very serous-ally bad mistake.

LAG post before yours gets it really right. Text based communication is quite bad. Its simple to take it as Linus being hard and miss there was a totally correct process to follow before getting to Linus to make sure you don't overwork Linus. We have seen how bad Linus temperament gets when he gets badly overworked and we don't need to put him back there.

Yes sometimes the only way to get your code reviewed is to request a merge by Andrew Morton(because you cannot get maintainer to respond or what you doing does not have a maintainer) or Greg Kroah-Hartman or the Next branch maintainer.

It use to be a old rule of the Linux kernel. "If you put patches and ask for review and hear nothing request a Merge into the correct branch to get review that way." Why will a lot not bother reviewing code until merge request its so they don't get over worked and requesting a merge you must personally believe the code is read or at least have some level of faith that the code is decent.

Linux kernel does have formal processes to cover the problems Kent was having on the mailing list and he failed to use them and if he has read the Linux kernel maintainers handbook as all maintainers are meant to when something is not going right he should have known the. But Kent is human and humans love avoiding reading manuals when they have problems and this sometimes get you into big trouble..

[pmorph]

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.

That's a weird way to look at it. It makes it sound like the rules are there just to annoy people, but with good enough stuff you may bribe the gatekeeper. In my view, the only excuse for such a "fast path" would be that something is already horribly broken, and you need to fix it fast (i.e. when the chance of it becoming worse than it already is, is negligible).

[timofonic]

I would class it as error in process. As maintainer of bcache Kent is allowed to short cut the process to a point. Yes a maintainer he can submit directly to the next tree.

There is a problem here. When you go though the Linux kernel documentation you find something.
"Andrew Morton serves as a maintainer of last resort."

You cannot find some maintainer to review your patch then you are meant to raise the issue with "Andrew Morton" who will either get some maintainer to review the code or review it himself. Now what you are working on you want into the Linux kernel but its not quite ready for users "Greg Kroah-Hartman" of the staging branch is for you.

As I said the documentation on this stuff is not clear enough. He did not place a "merge request" with either "Greg Kroah-Hartman" or "Andrew Morton" or Next branch or any other maintainer.

Please remember asking people to review your code that is asking humans to review you code. Put your code in the next branch asks the automated tools to review your code.

Linus could never do a final merge into head of kernel without having the signed of the automated tools as you get going though the next branch..

Khrundel yes i know how it appears but you have to remember Kent is a Linux kernel maintainer he should be following the kernel maintainers guidelines that include putting the code in the next tree by some means before bring the issue up with Linus. Yes with the fault that Linus is finding Kent would have submitted this code to the next tree and the automated reviews would have been no your code is not good enough please fix this and try again. So its understandable Linus is a bit annoyed he just worked out due to Kent not following correctly process he been wasting his time reviewing code and sending responses that he should not have been reviewing.

Patches moving though the Linux kernel trees in the correct way is party to make your Linux kernel master branch maintainers like Linus Torvalds and LTS maintainers don't get over worked and burnt out.

Think about it if every person who wants to submit code follows what Kent does how long until Linus himself is totally overloaded and burnout. So Kent seeing possible a simple solution has made a very serous-ally bad mistake.

LAG post before yours gets it really right. Text based communication is quite bad. Its simple to take it as Linus being hard and miss there was a totally correct process to follow before getting to Linus to make sure you don't overwork Linus. We have seen how bad Linus temperament gets when he gets badly overworked and we don't need to put him back there.

Yes sometimes the only way to get your code reviewed is to request a merge by Andrew Morton(because you cannot get maintainer to respond or what you doing does not have a maintainer) or Greg Kroah-Hartman or the Next branch maintainer.

It use to be a old rule of the Linux kernel. "If you put patches and ask for review and hear nothing request a Merge into the correct branch to get review that way." Why will a lot not bother reviewing code until merge request its so they don't get over worked and requesting a merge you must personally believe the code is read or at least have some level of faith that the code is decent.

Linux kernel does have formal processes to cover the problems Kent was having on the mailing list and he failed to use them and if he has read the Linux kernel maintainers handbook as all maintainers are meant to when something is not going right he should have known the. But Kent is human and humans love avoiding reading manuals when they have problems and this sometimes get you into big trouble..

Do you mean this is a RTFM issue? He has contributed large sets of code in the past, it seems is another cause and that means the situation for Bcachefs merge looks quite bad.

Maybe it's just that he has too much ego in a pathological level.

[Mr.Elendig]

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?

Imagine if all the 5k or how many active contributors sent all their work to Linus and went "I'm too special to follow the established procedure"

The kernel is way too large and active for any single person to keep track of all parts of it, review all incoming code and so on. The current "flow" for contributions was set up for really good reasons, and bypassing it not only needlessly increases the workflow for Linus, but it also reduces important input from the rest of the community and leaves a bad taste for those who do follow the proper procedures.

[timofonic]

Here's is a reply from Oracle's Chris Mason of Btrfs...

When we merged btrfs, Linus helped redo all of the btrfs out of tree commits on top of kernel git. I can't remember at this point if it was his idea or mine, but git history is obviously improved by remembering my sparse file joy:

commit 3a686375629da5d2e2ad019265b66ef113c87455
Author: Chris Mason <[email protected]>
Date: Thu May 24 13:35:57 2007 -0400

Btrfs: sparse files!

I'd have a preference for keeping the old history, warts and all, but wanted to give a data point to help jog people's memory around problems it might have caused.

Chris Mason discusses the integration of Btrfs into the Linux kernel. Linus Torvalds assisted in reorganizing the commits from Btrfs that were outside the main kernel repository.

Chris expresses a preference for retaining the original history of Btrfs (flaws and all), but highlights the need to provide additional context to remind people of potential issues caused by this history.

I wonder if Bcachefs patches face similar challenges with commits as Btrfs did in its early days. How has Bcachefs addressed these potential issues in its quest for inclusion into Linus branch?

[Errinwright]

The notion that he completely bypassed the maintainers and wasted Linus' time, is simply ignoring the history of attempting to get it merged. If you read all of the history, it is evident that everyone is at fault; furthermore, someone should have emphasized the lack of linux-next much earlier.

Edit: Also, making it seem as if BcacheFS merely is 'more code' seems to ignore the fact that the state of current filesystems in Linux is atrocious at best. There is a clear case to be made for prioritizing its implementation.

[timofonic]

The notion that he completely bypassed the maintainers and wasted Linus' time, is simply ignoring the history of attempting to get it merged. If you read all of the history, it is evident that everyone is at fault; furthermore, someone should have emphasized the lack of linux-next much earlier.

Edit: Also, making it seem as if BcacheFS merely is 'more code' seems to ignore the fact that the state of current filesystems in Linux is atrocious at best. There is a clear case to be made for prioritizing its implementation.

Excuse me for my ignorance...

How atrocious is it? Could you please elaborate more about it? I'm quite interested in knowing about it!

[Errinwright]

Excuse me for my ignorance...

How atrocious is it? Could you please elaborate more about it? I'm quite interested in knowing about it!

Performance is up to par for the most part, however, data integrity is often an issue due to garbled code which is being 'maintained' yet not refactored.

[timofonic]

Performance is up to par for the most part, however, data integrity is often an issue due to garbled code which is being 'maintained' yet not refactored.

Would you please provide examples about it at least?

What garbled code?

What data integrity issues happened because of it?

Do you consider Bcachefs have these issues too?

Is an issue of code from VFS subsystem(s), filesystems itself or something else?