Bcachefs Looks Like It Won't Make It For Linux 6.6

[oiaohm]

Okay. But those rules aren'tfollowed by corporate contributors. That's very hypocrite!.

That is not true. Corporate maintainers have got into trouble for the same stunt Kent tried to pay. The worse case when Linus worked out the corporate code got fully pulled.

Something everyone need to remember.

BCACHE (BLOCK LAYER CACHE)
M: Coly Li <[email protected]>
M: Kent Overstreet <[email protected]>
L: [email protected]
S: Maintained
W: http://bcache.evilpiepirate.org
C: irc://irc.oftc.net/bcache
F: drivers/md/bcache/

I have to think the only reason why bcache in mainline has been following the right process is the corporate contributor from suse who has been the other maintainer.

Part of why everyone in the Linux community is so annoyed with Kent Overstreet is that he is a maintainer.

There has been a nasty explosive blow ups with OpenBSD and FreeBSD when a committee member(Linux kernel equal to Maintainer) disobeyed policy.

[geearf]

Okay. But those rules aren'tfollowed by corporate contributors. That's very hypocrite!

I don't know, wasn't amdgpu.DC completely refused the first time it was sent and they had to redo a bunch of stuff to be in acceptable state?

[PuckPoltergeist]

I don't think so, I believe he dumped bcache a long time ago to focus on bcachefs and others that don't really know the codebase that well had to become the guys to fix it.

If this is the truth, we have the next case of ReiserFS. Abandoned for next point of interest, don't care anymore. This is a NoGo for a filesystem. Kent is listed as maintainer for bcache today.

[oiaohm]

That could be, but other involved parties don't care about upstreaming succeeding may be. So it's in his interest to avoid flaming it up since he cares.

It would be very annoying if this upstreaming fails not becasue of some technical issues, but becasue developers couldn't resolve how to work together.

You are right most of the pissed off Linux people don't care about bcachefs succeeding.

BCACHE (BLOCK LAYER CACHE)
M: Coly Li <[email protected]>
M: Kent Overstreet <[email protected]>
L: [email protected]
S: Maintained
W: http://bcache.evilpiepirate.org
C: irc://irc.oftc.net/bcache
F: drivers/md/bcache/

shmerl the big problem is Kent Overstreet is a maintainer who does have the right to submit code to the Next branch. What if Coly is away is Kent Overstreet going to try to go direct to Linus and get something submitted without the automated tools being run over the code leading to bugs getting to end users.

With great power comes great responsibility. Its a great power to be a Linux kernel maintainer and with the damage it can do not following policy is a very fast way to have pitch forks out.

Kent Overstreet is not the first Maintainer to get caught doing stuff like this causing the Linux kernel core developers to get very annoyed. Please note Linux core developers have not decided to have Andrew Morton strip Kent Overstreet of is maintainer-ship of bcache.

FreeBSD and OpenBSD have both kicked people out of their committee for the exact same offenses Kent Overstreet has done. Yes by FreeBSD and OpenBSD we would not be having this debate because by both of those rules you do a mistake like Kent Overstreet has done that is a removal from the committee and ban from being on the committee for your complete lifetime. Yes everyone would have been over as soon as Kent Overstreet had done this mistake with FreeBSD and OpenBSD.

You might call the Linux community toxic but you overlooked some of the reason why FreeBSD and OpenBSD has had a harder time getting maintainers than Linux is a lower tolerance level. Yes the Linux kernel community may not be the nicest but they will accept that humans make human errors and give parties second chances.

[PuckPoltergeist]

Anyway, I think Kent should get heavy support and advocacy on LKML. Despite his failures, he doesn't deserve this level of backslash. I'm nobody, but kernel developers can be heard.

Already noticed, Kent is maintainer of bcache. He should know the rules of kernel development. This sounds more and more like Reiser4, when Hans Reiser tried to push his point of view. He is the only one who is right, All the others have to accept and adopt.

[oiaohm]

I don't know, wasn't amdgpu.DC completely refused the first time it was sent and they had to redo a bunch of stuff to be in acceptable state?

AmdGPU had to do multi passes at the next branch being rejected by the bots over and over again. The paid AMD developers were getting really upset and started thinking Intel o-day linux kernel auditing bot was out to get them. Yes the first time into the Linux kernels was multi redoes with the automated tools finding more and more mistakes. Yes Amd developers also though when they attempt to submit upstream that there code base was in very good condition and were very proud of what they did up until that point and that was some of the reason why they did not take being ripped a new one by the bots.

Having your code audited even by a non human can cause human to have mental problems due to humans not exactly like being pointed out they have made mistakes..

The one with the most amount of rejects is the Linux kernel RT branch by both humans and bots.

There is a special case of stubborn to make quality code particularly with how many times it going to be pointed out that your code is wrong.

[nadir]

All your you have to respect them, Linus himself was very rude very often, and he was like him when he was young, he calls himself dictator, Kent seems to not be rude from what I hear I don't hear him name calling and stuff.

Also in essence it comes down that this requirements that you all like so much, are much more easy to reach for corporations, so the trend that more and more % code is done by the evil corporations will be extended by this approach.

And Linus was wrong when he was being rude. It was accepted because he is the guy who invented the damn thing but it was absolutely a bad thing to behave that way. He stopped because people pointed out to him that it was a problem and he worked on himself, which is great.

You should learn from that that issues can be overcome, not that because somebody important and admirable was also a dick sometimes, it must therefore be fine to be a dick.

Kent was certainly quite rude and you just can't deal with criticism that way if you want your stuff to get merged. Being rude is really bad form and makes everything much more difficult for everybody.

The blocking issue though was that he failed to put things in linux_next, something that he definitely must have known. I don't know where you're getting your incredible requirements from that can only be met by large corporations.

Don't be rude, put things in linux_next, work with the other subsystem people. If they have criticisms you disagree with, that's still something you have to deal with without being rude. If they're being rude, don't reciprocate because you're the one wanting something done.

If you fail at that and have another three months to get things done, maybe do things correctly.

[blackiwid]

I don't like this sort of communication I don't know all the maintainers communication how fast they responded if they answered all questions or reasoned for their blocks or anything but just going by the mail from Linus this is super toxic by him:

1. he said you should have done A and B, he does not say if you do A or B in time we add it, so it's just 2 hoops to spring through with a open amount of additional hoops is it then enough are there 2 5 5000 other hoops?

2. he somewhat admitted that he did not notice that the code is not in linux-next, but it's more like "ok I don't blame you for it" not that "if I would have noticed I would not have caused you to not get added now".

That's like going to a government agency, they invite you tell you maybe bring A B C then you come in mid of your job, and they say did nobody tell you that you need D E and F also, and after you bring that they mention G H I... and worse not having a clear procedure where it's clear that A to I will get you in, the file manager can make up new rules as "Dictator" on the fly, and if you were not nice enough to the secretary in the way in, you get send home also.

Now you have to bring some bribery sweets for the secretary to make it happen to get around this corrupt dictatorship without clear rules.

It's absurd and unprofessional, he is not some random shmonk or somebody from the enemy of the system from Microsoft, that tries to destroy linux, if they somehow can or sabotage it, or some guy that brings in some 5 liner Crap Bugfix, it's a big thing, people say well we have btrfs, but how much effort and attention the way lesser Filesystem xfs gets and oh wonder that maintainer get burned out by this crap, too, btw. And it's no big deal to find 5 other people to maintain his system that is basically identical to ext4, jfs and co.

I think calling that kafka-esk is totally fine.

Linus should have apologized that he and his underlings are the reason that it can't not be integrated if linux-next is a hard blocker then telling him some time wasting hoops that will not bypass this is a insult and time wasting, if that would be possible to bypass it he should have said it in that mail. It's literally like a government agency.

Maybe there is need for getting rid of this linux Kernel monopoly.

[geearf]

If this is the truth, we have the next case of ReiserFS. Abandoned for next point of interest, don't care anymore. This is a NoGo for a filesystem. Kent is listed as maintainer for bcache today.

I believe it's the same yeah, Hans abandoned ReiserFS for Reiser4 and I think RH took over the maintenance, whether with bcache Suze took over.
While he may still be listed as maintainer, I'm not sure he's done any maintaining in a while: https://git.kernel.org/pub/scm/linux.../bcache?h=v6.5
But you know, a single guy can only do so much.

AmdGPU had to do multi passes at the next branch being rejected by the bots over and over again. The paid AMD developers were getting really upset and started thinking Intel o-day linux kernel auditing bot was out to get them. Yes the first time into the Linux kernels was multi redoes with the automated tools finding more and more mistakes. Yes Amd developers also though when they attempt to submit upstream that there code base was in very good condition and were very proud of what they did up until that point and that was some of the reason why they did not take being ripped a new one by the bots.

Having your code audited even by a non human can cause human to have m

If this is the truth, we have the next case of ReiserFS. Abandoned for next point of interest, don't care anymore. This is a NoGo for a filesystem. Kent is listed as maintainer for bcache today.

ental problems due to humans not exactly like being pointed out they have made mistakes..

The one with the most amount of rejects is the Linux kernel RT branch by both humans and bots.

There is a special case of stubborn to make quality code particularly with how many times it going to be pointed out that your code is wrong.

Yeah that was harsh and you're right it's hard to keep going at it, that's pretty much why I stopped contributing to Mesa the review just broke my ego too much.

[PuckPoltergeist]

I think calling that kafka-esk is totally fine.

Again, Kent is a kernel maintainer. He should know the rules, he must know it. If it's kafka-esk for him, why he didn't disagree before?