3 ms·

He justified breaking the guidelines to address critical issues. one can hope these kind of problems would not happen that frequently in a stable project, besid

He justified breaking the guidelines to address critical issues. one can hope these kind of problems would not happen that frequently in a stable project, besides it is still experimental.

mrweasel 1y ago
My take away from trying to follow the discussion on the kernel mailing list was that the Bcachefs developer want to work in a certain way, that Linus does not think that fit in with the rest of the kernel (to put it mildly). Having Bcachefs in the kernel certainly helps with adoption, but I can't help thinking that a kernel module might be more inline with the development process that Bcachefs wants. The underlying problem might have been importing Bcachefs into the mainline kernel to early in it's life cycle.
- jeltz 1y ago
  No, this is a pure people problem which would have happened no matter the state of Bcachefs. Kent refuses to respect other people's time and rules since that would require him to change how he works.
  - typpilol 1y ago
    On the other hand, Linus is constantly changing the submit times based on his own personal travel. A lot of people aren't going to keep up with Linus personal travel plans just so they don't send a late patch.
ranger_danger 1y ago
Except he had a history of rushing large changes in at the last minute that were always critical, and would constantly argue about policy during the same time, which is not the appropriate time or place. He refused to acknowledge his place on the totem pole and thought he knew better than everyone else, and that they should change their ways to suit his whims.
- cogman10 1y ago
  The way I read it, it was wrapping in feature and bug fix changes. "We found a critical bug here, to fix it instead of backporting a fix we want to pull in all the code which was built before the bug was discovered". I can understand the motivation. It's a PITA to support an older version of code. But that's not how linux gets it's stability.
  - fooqux 1y ago
    That's just bad git hygiene, and lots of lead devs deal with this across the development world. One change per commit/PR please.
    - cogman10 1y ago
      I think it's more natural. Commit A: introduce the bug Commit B: change architecture Commit C: add a feature Commit D: fix A using code present in B and C. The issue ends up being that D needs to be reimplemented to fix A because B and C don't exist on the tip. Since linux has closed windows and long term kernels it means the fix to the same bug could need to be done in multiple ways. Multiple changes per PR is bad, but I assume it's still one change per commit.
      - fooqux 1y ago
        Yeah, but then you run into scenarios where A+D is tested and ready, but B and/or C are not. Git does give you tools to separate them, but most people don't like doing that for various reasons. IMHO, it may be more natural, but only during development. Trying to do a git bisect on git histories like the above is a huge pain. Trying to split things up when A is ready but B/C are not is a huge pain.
  - MBCook 1y ago
    He also had bad interactions with other developers, like constantly shitting on other file systems and generally behaving like a jerk completely unnecessarily.
  - 1y ago
mrktf 1y ago
As for occasional follower, my opinion is that: Kent overdid with bending rules until Linus & co got fed up.
happymellon 1y ago
> He justified breaking the guidelines to address critical issues That claim was to add new logging functionality to allow better troubleshooting to eventually address critical issues. This should have been out of trunk for someone to test, rather than claiming it to be something that wasn't strictly true. Especially when it's the kernel.
jeltz 1y ago
What he actually did was that he bundled the fix for the critical issue with dubugging tools and a totally new experimental feature. I totally get why they stopped working with him.
- bcrl 1y ago
  A feature that was put in place to allow users encountering the bug to recover their data. It's not as black and white as you are portraying.
  - jeltz 1y ago
    It was still an entirely new and experimental feature which had not been properly reviewed. Why couldn't this feature wait until next kernel version? Other file systems have had their recovery tools improved over many years.
    - bcrl 1y ago
      Filesystems like ext2/3/4 have their recovery tools in userland. Most of the recovery features in bcachefs are in the kernel. As a result, it is inevitable that at some point there was and will be a need to push a new feature into a stable release for the purpose of data recovery. Over the long term the number of cases where such a response is needed will decrease as expected. Do you really want to live in a world where data losses in stable releases is considered Okay?
      - streb-lo 1y ago
        That's a good argument to keep recovery tools in userland rather than bend the kernel around them. Why do they need to be in the kernel anyways? Presumably they are running on an unmounted device?
        bcrl 1y ago
        No, it is not. bcachefs needs to have all the code for error recover in the kernel as it needs to be available when a storage device fails in any of a myriad of ways. Maintaining a piece of code that needs to run in both user space and the kernel is messy and time consuming. You end up running into issues where dependencies require the porting of gobs of infrastructure from the kernel into userspace. That's easy for some thing, very hard for others. There's a better place to spend those resource: by stabilizing bcachefs in the kernel where it belongs. Other people have tried and failed at this before, and I'm sure that someone will try the same thing again in the future and relearn the same lesson. I know as business requirements for a former employer resulted in such a beast. Other people thought they could just run their userspace code in the kernel, but they didn't know about limits on kernel stack size, they didn't know about contexts where blocking vs non-blocking behaviour is required or how that interacted with softirqs. Please, just don't do this or advocate for it.

He justified breaking the guidelines to address critical issues. one can hope these kind of problems would not happen that frequently in a stable project, besides it is still experimental.

mrweasel 1y ago

My take away from trying to follow the discussion on the kernel mailing list was that the Bcachefs developer want to work in a certain way, that Linus does not think that fit in with the rest of the kernel (to put it mildly). Having Bcachefs in the kernel certainly helps with adoption, but I can't help thinking that a kernel module might be more inline with the development process that Bcachefs wants. The underlying problem might have been importing Bcachefs into the mainline kernel to early in it's life cycle.

jeltz 1y ago
No, this is a pure people problem which would have happened no matter the state of Bcachefs. Kent refuses to respect other people's time and rules since that would require him to change how he works.
- typpilol 1y ago
  On the other hand, Linus is constantly changing the submit times based on his own personal travel. A lot of people aren't going to keep up with Linus personal travel plans just so they don't send a late patch.

ranger_danger 1y ago

Except he had a history of rushing large changes in at the last minute that were always critical, and would constantly argue about policy during the same time, which is not the appropriate time or place. He refused to acknowledge his place on the totem pole and thought he knew better than everyone else, and that they should change their ways to suit his whims.

cogman10 1y ago
The way I read it, it was wrapping in feature and bug fix changes. "We found a critical bug here, to fix it instead of backporting a fix we want to pull in all the code which was built before the bug was discovered". I can understand the motivation. It's a PITA to support an older version of code. But that's not how linux gets it's stability.
- fooqux 1y ago
  That's just bad git hygiene, and lots of lead devs deal with this across the development world. One change per commit/PR please.
  - cogman10 1y ago
    I think it's more natural. Commit A: introduce the bug Commit B: change architecture Commit C: add a feature Commit D: fix A using code present in B and C. The issue ends up being that D needs to be reimplemented to fix A because B and C don't exist on the tip. Since linux has closed windows and long term kernels it means the fix to the same bug could need to be done in multiple ways. Multiple changes per PR is bad, but I assume it's still one change per commit.
    - fooqux 1y ago
      Yeah, but then you run into scenarios where A+D is tested and ready, but B and/or C are not. Git does give you tools to separate them, but most people don't like doing that for various reasons. IMHO, it may be more natural, but only during development. Trying to do a git bisect on git histories like the above is a huge pain. Trying to split things up when A is ready but B/C are not is a huge pain.
- MBCook 1y ago
  He also had bad interactions with other developers, like constantly shitting on other file systems and generally behaving like a jerk completely unnecessarily.
- 1y ago

mrktf 1y ago

As for occasional follower, my opinion is that: Kent overdid with bending rules until Linus & co got fed up.

happymellon 1y ago

> He justified breaking the guidelines to address critical issues That claim was to add new logging functionality to allow better troubleshooting to eventually address critical issues. This should have been out of trunk for someone to test, rather than claiming it to be something that wasn't strictly true. Especially when it's the kernel.

jeltz 1y ago

What he actually did was that he bundled the fix for the critical issue with dubugging tools and a totally new experimental feature. I totally get why they stopped working with him.

bcrl 1y ago
A feature that was put in place to allow users encountering the bug to recover their data. It's not as black and white as you are portraying.
- jeltz 1y ago
  It was still an entirely new and experimental feature which had not been properly reviewed. Why couldn't this feature wait until next kernel version? Other file systems have had their recovery tools improved over many years.
  - bcrl 1y ago
    Filesystems like ext2/3/4 have their recovery tools in userland. Most of the recovery features in bcachefs are in the kernel. As a result, it is inevitable that at some point there was and will be a need to push a new feature into a stable release for the purpose of data recovery. Over the long term the number of cases where such a response is needed will decrease as expected. Do you really want to live in a world where data losses in stable releases is considered Okay?
    - streb-lo 1y ago
      That's a good argument to keep recovery tools in userland rather than bend the kernel around them. Why do they need to be in the kernel anyways? Presumably they are running on an unmounted device?
      - bcrl 1y ago
        No, it is not. bcachefs needs to have all the code for error recover in the kernel as it needs to be available when a storage device fails in any of a myriad of ways. Maintaining a piece of code that needs to run in both user space and the kernel is messy and time consuming. You end up running into issues where dependencies require the porting of gobs of infrastructure from the kernel into userspace. That's easy for some thing, very hard for others. There's a better place to spend those resource: by stabilizing bcachefs in the kernel where it belongs. Other people have tried and failed at this before, and I'm sure that someone will try the same thing again in the future and relearn the same lesson. I know as business requirements for a former employer resulted in such a beast. Other people thought they could just run their userspace code in the kernel, but they didn't know about limits on kernel stack size, they didn't know about contexts where blocking vs non-blocking behaviour is required or how that interacted with softirqs. Please, just don't do this or advocate for it.