4 ms·

You still seem to be arguing that, shipping the change was the "right" thing to do. But that's not what's in dispute. Rather it is that, if what you think is ri

You still seem to be arguing that, shipping the change was the "right" thing to do. But that's not what's in dispute. Rather it is that, if what you think is right and what the person who makes the rules thinks is right are in disagreement, the adult thing to do is not to simply disregard the rules (and certainly not repeatedly, after being warned not to). This is the difference between being smart and being wise. If the goal of all this grandstanding was that, it's so incredibly and vitally important for these patches to get into the kernel, well guess what, now due to all this drama this part of the kernel is going to go unmaintained entirely. Is that good for the users? Did that help our stated goal in any way? No.

charcircuit 1y ago
>the adult thing to do is not to simply disregard the rules The adult thing is to do best by the users. Critical file system bugs are worth blocking the release of any serious operating system in the real world as there is serious user impact. >Is that good for the users? I think it's complicated. It could allow for a faster release schedule for bug fixes which can allow for addressing file system issues faster.
- nirava 1y ago
  > The adult thing is to do best by the users Best by users in the long term is predictable processes. "RC = pure bug fixes" is a battle tested, dependable rule, absence of which causes chaos. > Critical file system bugs are worth blocking the release "Experimental" label EXACTLY to prevent this stuff from blocking release. Do you not know that bcachefs is experimental? This is an example of another rule which helps predictability.
  - charcircuit 1y ago
    This was a bug fix. My point is that there will always be bugs in the kernel so not all bugs are worth blocking a release, but losing data is worth blocking the release for. >"Experimental" label EXACTLY to prevent this stuff from blocking release In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label.
    - motorest 1y ago
      > This was a bug fix. I'm not sure exactly what you are talking about, and I'm not sure you do either. The discussion that preceded bcachefs to be dropped from the Linux kernel mainline involved an attempt to sneak a new features in RC, sidestepping testing and QA work, which was followed up by yet more egregious behavior from the mantainer. https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Feature https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur...
      - charcircuit 1y ago
        >sneak a new features in RC Too solve a bug with the filesystem that people in the wild were hitting. Like how Linus has said in the past with how there is a blurry line between security fixes and bug fixes. There is a blurry line between filesystem bugs and recovery features. If you read the email it is clear that the full feature has more work needed and this is more of a basic implementation to address bugs that people hit in the wild.
        motorest 1y ago
        > Too solve a bug with the filesystem that people in the wild were hitting. So you acknowledge that this last episode involved trying to push new features into a RC. As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions. All these red flags were repeatedly raised in the mailing list by multiple kernel maintainers. Somehow you're ignoring all the feedback and warnings and complains raised by people from Linux kernel maintainers, and instead you've opted to try to gaslight the thread.
        koverstreet 1y ago
        No, I'm sorry but you're simply wrong. bcachefs has a ton of QA, both automated testing and a lot of testers that run my latest and I work with on a daily basis. The patch was well tested; it was for codepaths that we have good regression tests for, it was algorithmically simple, and it worked perfectly to recover a filesystem from the original bug report, and it performed flawlessly again not long after. I've explained my testing and QA on the lists multiple times. You, like the other kernel maintainers in that thread, are making wild assertions despite having no involvement with the project.
- saubeidl 1y ago
  I don't think getting the FS kicked out of the kernel is best by the users. Good engineering requires long term thinking.
  - procaryote 1y ago
    There's more than bcachefs in the kernel. If dealing with bcachefs takes an inordinate amount of time and effort, dropping it is the right move. I don't know the situation well enought to review where they drew the line, but there definitely should be a line somewhere.
    - saubeidl 1y ago
      That was my point exactly.

charcircuit 1y ago

>the adult thing to do is not to simply disregard the rules The adult thing is to do best by the users. Critical file system bugs are worth blocking the release of any serious operating system in the real world as there is serious user impact. >Is that good for the users? I think it's complicated. It could allow for a faster release schedule for bug fixes which can allow for addressing file system issues faster.

nirava 1y ago
> The adult thing is to do best by the users Best by users in the long term is predictable processes. "RC = pure bug fixes" is a battle tested, dependable rule, absence of which causes chaos. > Critical file system bugs are worth blocking the release "Experimental" label EXACTLY to prevent this stuff from blocking release. Do you not know that bcachefs is experimental? This is an example of another rule which helps predictability.
- charcircuit 1y ago
  This was a bug fix. My point is that there will always be bugs in the kernel so not all bugs are worth blocking a release, but losing data is worth blocking the release for. >"Experimental" label EXACTLY to prevent this stuff from blocking release In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label.
  - motorest 1y ago
    > This was a bug fix. I'm not sure exactly what you are talking about, and I'm not sure you do either. The discussion that preceded bcachefs to be dropped from the Linux kernel mainline involved an attempt to sneak a new features in RC, sidestepping testing and QA work, which was followed up by yet more egregious behavior from the mantainer. https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Feature https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur...
    - charcircuit 1y ago
      >sneak a new features in RC Too solve a bug with the filesystem that people in the wild were hitting. Like how Linus has said in the past with how there is a blurry line between security fixes and bug fixes. There is a blurry line between filesystem bugs and recovery features. If you read the email it is clear that the full feature has more work needed and this is more of a basic implementation to address bugs that people hit in the wild.
      - motorest 1y ago
        > Too solve a bug with the filesystem that people in the wild were hitting. So you acknowledge that this last episode involved trying to push new features into a RC. As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions. All these red flags were repeatedly raised in the mailing list by multiple kernel maintainers. Somehow you're ignoring all the feedback and warnings and complains raised by people from Linux kernel maintainers, and instead you've opted to try to gaslight the thread.
        koverstreet 1y ago
        No, I'm sorry but you're simply wrong. bcachefs has a ton of QA, both automated testing and a lot of testers that run my latest and I work with on a daily basis. The patch was well tested; it was for codepaths that we have good regression tests for, it was algorithmically simple, and it worked perfectly to recover a filesystem from the original bug report, and it performed flawlessly again not long after. I've explained my testing and QA on the lists multiple times. You, like the other kernel maintainers in that thread, are making wild assertions despite having no involvement with the project.
saubeidl 1y ago
I don't think getting the FS kicked out of the kernel is best by the users. Good engineering requires long term thinking.
- procaryote 1y ago
  There's more than bcachefs in the kernel. If dealing with bcachefs takes an inordinate amount of time and effort, dropping it is the right move. I don't know the situation well enought to review where they drew the line, but there definitely should be a line somewhere.
  - saubeidl 1y ago
    That was my point exactly.