7 ms·

> 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

by 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.
        motorest 1y ago
        > No, I'm sorry but you're simply wrong. It sounds like you have a hard time coping with reality. https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Feature https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur... I repeat: it sounds an awful lot like you are trying to gaslight this thread. Not cool. When this fact was again explicitly pointed out to you by Linus himself, you even tried to bullshit Linus and try to move the goalpost with absurd claims about how somehow it was ok to force untested and unreviewed features into a RC because somehow you know better about what users want or need as if it was some kind of justification for you to skip testing and proper release processes. You need to set aside some time for introspection because you sound like you are your own worst enemy. And those you interact with seem to be fed up and had enough of these stunts.
- dijksterhuis 1y ago
  > 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. alternative perspective: those users have knowingly and willingly put experimental software into production. it was their choice, they were informed of the risk and so the consequences and responsibility are their’s. it’s like signing up to take some experimental medicine, and then complaining no-one told me about the side-effect of persistent headaches. that doesn’t stop anyone from being user-centric in their approach, e.g. call me if you notice any symptoms and i’ll come round your house to examine you. … as long as everyone is clear about the fact it is experimental and the boundaries/limitations that apply, e.g. there will be certain persistent headache medicines that cannot be prescribed to you, or it might take longer for them to work because you’re on an experimental medicine.
  - koverstreet 1y ago
    Again: the elephant in the room is that a lot of bcachefs users are using it explicitly because they have lost a lot of data on btrfs, and they've found it to be more trustworthy. This puts us all in a shitty situation. I want the experimental label to come off at the right time - when every critical bug is fixed and it's as trustworthy as I can reasonably make it, when I know according to the data I have that everyone is going to have a good experience - but I have real users who need this thing and need to be supported. There is _no reason_ to interpret the experimental label in the way that you're saying, you're advocating that reliability for the end user be deprioritized versus every other filesystem. But deprioritizing reliability is what got us into this mess.
    - rob_c 1y ago
      >users are using it explicitly because they have lost a lot of data on btrfs PLEASE, honestly, EDUCATE THESE USERS. This is still marked experimental for numerous reasons regardless of the 'planned work for 6.18'. Users who can't suffer any data loss and are repeating their mistake of using btrfs shouldn't be using a none default/standard/hardened filesystem period.

by nirava 1y ago

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.
      - motorest 1y ago
        > No, I'm sorry but you're simply wrong. It sounds like you have a hard time coping with reality. https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Feature https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur... I repeat: it sounds an awful lot like you are trying to gaslight this thread. Not cool. When this fact was again explicitly pointed out to you by Linus himself, you even tried to bullshit Linus and try to move the goalpost with absurd claims about how somehow it was ok to force untested and unreviewed features into a RC because somehow you know better about what users want or need as if it was some kind of justification for you to skip testing and proper release processes. You need to set aside some time for introspection because you sound like you are your own worst enemy. And those you interact with seem to be fed up and had enough of these stunts.
dijksterhuis 1y ago
> 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. alternative perspective: those users have knowingly and willingly put experimental software into production. it was their choice, they were informed of the risk and so the consequences and responsibility are their’s. it’s like signing up to take some experimental medicine, and then complaining no-one told me about the side-effect of persistent headaches. that doesn’t stop anyone from being user-centric in their approach, e.g. call me if you notice any symptoms and i’ll come round your house to examine you. … as long as everyone is clear about the fact it is experimental and the boundaries/limitations that apply, e.g. there will be certain persistent headache medicines that cannot be prescribed to you, or it might take longer for them to work because you’re on an experimental medicine.
- koverstreet 1y ago
  Again: the elephant in the room is that a lot of bcachefs users are using it explicitly because they have lost a lot of data on btrfs, and they've found it to be more trustworthy. This puts us all in a shitty situation. I want the experimental label to come off at the right time - when every critical bug is fixed and it's as trustworthy as I can reasonably make it, when I know according to the data I have that everyone is going to have a good experience - but I have real users who need this thing and need to be supported. There is _no reason_ to interpret the experimental label in the way that you're saying, you're advocating that reliability for the end user be deprioritized versus every other filesystem. But deprioritizing reliability is what got us into this mess.
  - rob_c 1y ago
    >users are using it explicitly because they have lost a lot of data on btrfs PLEASE, honestly, EDUCATE THESE USERS. This is still marked experimental for numerous reasons regardless of the 'planned work for 6.18'. Users who can't suffer any data loss and are repeating their mistake of using btrfs shouldn't be using a none default/standard/hardened filesystem period.