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

[blackiwid]

So now we have the risk of friction in the Kernel Team we avoided, BUT it looks to me that at least in Kernel 6.7 there will also not be a bcachefs UNLESS they try to help him instead of only saying you should do X Y Z and beg some people that gave no reason for their rejection that they finally give a real statement or something.

The only thing that from my intuition could motivate Kent would be that there are some bakers give him money to accept the unnecessary kafkaesce situation and pain.

But to burn out such a young great developer to force him to go through a kafkaesk which you could also just call abusive humiliating process where he has to show basically that this old folks are somehow superior to him even they maybe never done such great big project at least some of them, is never good even if he does it.

Not only does it delay the delivery of the better product, but also steels developer time and increases stress on him so the product will be worse than it could be without that interference.

Even having 3-x attempts to merge it instead of 1 binds lot's of developer time even without burnout and slow email communication and waiting times.

So I nearly hope now that Kent states that he will not try to integrate it in 6.7 than only that would maybe make the kernel devs to question their attitudes and rules.
(and sorry I am to lazy to google the pronunciation of Kafka-esk)

About the mailing list, there might be disadvantage and yes some folks that want not have any learning courve would see it as disadvantage that you have no or bad browser access to it. But on the other side of the coin you have in my example Emacs but surely other NNTP tools that are directly integrated in your IDE and stuff now maybe there is some sort of integration that don't involve the slow and very limited configurable (shortcuts) browser for Visual Studio or so, but if we talk for the best IDE Emacs, as example and surely VIM and others to my knowledge there exist no non-browser based interface, so yes NNTP / Mailinglists might have some disadvantages but the Web based newer Systems should address the horrible shortcomings of there systems have nntp Access or something similar otherwise it will always be like playing chess over mail, browsers are unacceptable UIs, you don't want to render something and have to dictate by the developers how it looks and all the shortcuts are...

[patrick1946]

What a strange word... I had to look that up on StartPage:

It is well known in German culture. But what he is describing is not really catching it. kafkaesque is much stronger. Even if you have the best social abilities you are helpless but what we here see is the typical programmer level of social abilities. ;-)

[blackiwid]

It is well known in German culture. But what he is describing is not really catching it. kafkaesque is much stronger. Even if you have the best social abilities you are helpless but what we here see is the typical programmer level of social abilities. ;-)

Maybe but why should we burden very rare seeked out individuals that are geniuses, and burden them with such crap? And in this hostile abusive way, RTFM style just with changing rules or people not answering emails in time.

This qualities he brings are rare, so people around him should try to make it easier for him not harder like they apparently do.

Him having a existential crisis contemplating adding it to the kernel at all, hurts Linux users more than him. Even if he overcomes everything, he is more burned out the product will have worse quality, because of this interaction that is without a doubt.

[blackiwid]

Just make 1 thought experiment assume that btrfs would not exist maybe not even ZFS, if that results in much delayed or maybe even not adding bcachefs to the kernel and having not 1 COW filesystem in the Kernel would be a disaster, from image point of view, freebsd people would make fun of linux for having a major advantage over linux and in the reasons to switch to linux from windows there would be a major point be crossed.

So the only way this discussion is even a question which side is more reasonable is because BTRFS exists already.

[kreijack]

Linux process could be better indeed. I landed a single line change a while ago, it required a lot of setup, tweaking Thunderbird (and failing to format message properly anyway because of long-standing Thuderbird issues) and in the end it was a very frustrating and long process with a lot of correspondence back and forth.

Compare that to a simple pull request process through platforms like GitHub, GitLab and similar.

To me it is Thunderbird the guilty. It handles very bad the sending of patches. On other side I don't think that setting the environment to send patch to a ML is an insurmountable problem. Or let me say otherwise: if someone aren't enable to do a similar setup, likely he aren't enough skilled to check the effect of the patch that is being sent. So it is possible that this barrier is wanted to avoid to be flowed by patches written by not enough skilled people.

[nazar-pc]

To me it is Thunderbird the guilty. It handles very bad the sending of patches. On other side I don't think that setting the environment to send patch to a ML is an insurmountable problem. Or let me say otherwise: if someone aren't enable to do a similar setup, likely he aren't enough skilled to check the effect of the patch that is being sent. So it is possible that this barrier is wanted to avoid to be flowed by patches written by not enough skilled people.

I think that is a flawed reasoning. It is like folks arguing that Rust is unnecessary, it is programmers that are bad that don't know how to write safe C. If this happens over and over again with C then maybe the language plays a factor here too?

I consider myself as fairly experienced engineer, writing code that is used in production for ~15 years and working with some cutting edge stuff. Clearly capable of setting up the environment. The issue though is that I need to configure a very specific workflow that is unique and uses very specific tools in a very specific way just to contribute a single line change to the kernel. For example I need to use email to send code, I need to send it in plain text, if the email client I use literally for everything else I need to set up sending patches via CLI somehow, figure out how to store credentials for it such that I neither need to enter them every time nor store in files in plain text. That is a HUGE barrier for anyone considering to contribute even remotely. Heck, I suffered with commit messages, I was trying to figure out how do I format the message to not exceed imposed length limit because apparently someone uses 30 years old monitor without horizontal scrolling capability or text wrapping and will be unable to read it otherwise.

While if it was any other project on GitHub, I'd clone the repo, change the line, commit with sign-off (added by IDE automatically if upstream requires), push it back to fork and create a PR with a few clicks. That is what I do many times every day with almost every other project.

For example Gstreamer moved from mailing list to GitLab and I think everyone was happy with it and I even contributed there a few times. I most likely wouldn't if it was still mailing list. And I would think a few times before going through the trouble trying to contribute to Linux again. Not because I am not capable of, the burden of doing so is way too high and, arguably, unnecessarily so (accidental complexity).

[sheepdestroyer]

What a strange word... I had to look that up on StartPage:

It's very common, in French too. It refers to overburdening and crazy bureaucracy.

[kreijack]

Just make 1 thought experiment assume that btrfs would not exist maybe not even ZFS, if that results in much delayed or maybe even not adding bcachefs to the kernel and having not 1 COW filesystem in the Kernel would be a disaster, from image point of view, freebsd people would make fun of linux for having a major advantage over linux and in the reasons to switch to linux from windows there would be a major point be crossed.

So the only way this discussion is even a question which side is more reasonable is because BTRFS exists already.

I don't understand why the people is dramatizing the situation. Nobody would be able to add a filesystem without a pull from the inside the kernel folks. I think that there is some interest to merge the Kent work. But it is to Kent to simplify the process.
Why ? Because from one side there is an interesting fs that HAS TO prove to be good; from the other side there is a project that is deployed in billion of devices and to which it is requested to provide some guarantee to the stakeholders. So it is natural a conservative approach from the Linux folks.

Everywhere it is written that contributing to the kernel is not an easy task. Kent was not the first and will be not the last people that get frustrated by this process. But if he is giving up when is facing simple human relationship "problem", what if there is be a bigger problem (like finding trade off between performance, backward compatibility, security....)

Finally, bcahefs is in development from about 10years; I don't think that it does matter if it is merged now, tomorrow or the next year.

[kreijack]

I think that is a flawed reasoning. It is like folks arguing that Rust is unnecessary, it is programmers that are bad that don't know how to write safe C. If this happens over and over again with C then maybe the language plays a factor here too?

The way to share the code is unrelated to the quality of the code; and if this is not true... then the problem is in the developer; anyway C vs Rust is a very different situation.

I consider myself as fairly experienced engineer, writing code that is used in production for ~15 years and working with some cutting edge stuff. Clearly capable of setting up the environment. The issue though is that I need to configure a very specific workflow that is unique and uses very specific tools in a very specific way just to contribute a single line change to the kernel. For example I need to use email to send code, I need to send it in plain text, if the email client I use literally for everything else I need to set up sending patches via CLI somehow, figure out how to store credentials for it such that I neither need to enter them every time nor store in files in plain text. That is a HUGE barrier for anyone considering to contribute even remotely. Heck, I suffered with commit messages, I was trying to figure out how do I format the message to not exceed imposed length limit because apparently someone uses 30 years old monitor without horizontal scrolling capability or text wrapping and will be unable to read it otherwise.

I think that you approaching the problem in the wrong way. To send the patch I use a script and "git send-email". This because using an email client is too complicated.
I think that this is the same debate CLI vs GUI. Yes a GUI apparently is more easy; but if you want to do complicated things a GUI doesn't scale very well.

While if it was any other project on GitHub, I'd clone the repo, change the line, commit with sign-off (added by IDE automatically if upstream requires), push it back to fork and create a PR with a few clicks. That is what I do many times every day with almost every other project.

For example Gstreamer moved from mailing list to GitLab and I think everyone was happy with it and I even contributed there a few times. I most likely wouldn't if it was still mailing list. And I would think a few times before going through the trouble trying to contribute to Linux again. Not because I am not capable of, the burden of doing so is way too high and, arguably, unnecessarily so (accidental complexity).

You don't have to convince me that GitLab/GitHub is more user friendly. You have to convince some people that drive a billionaire industry. Even if you are right, they are more right than you by several order of magnitude (I am joking a bit ... but not too much).

[nazar-pc]

The way to share the code is unrelated to the quality of the code; and if this is not true... then the problem is in the developer; anyway C vs Rust is a very different situation.



I think that you approaching the problem in the wrong way. To send the patch I use a script and "git send-email". This because using an email client is too complicated.
I think that this is the same debate CLI vs GUI. Yes a GUI apparently is more easy; but if you want to do complicated things a GUI doesn't scale very well.



You don't have to convince me that GitLab/GitHub is more user friendly. You have to convince some people that drive a billionaire industry. Even if you are right, they are more right than you by several order of magnitude (I am joking a bit ... but not too much).

I was just saying that the process they have in place right now, while seemingly works well for upstream, could still be improved a lot and that will drive more people in that do actually have something useful to contribute.