4 ms·

That is a valid objection, but I still think that for some huge and difficult features the month long pauses imposed by release cycles are absolutely detrimenta

That is a valid objection, but I still think that for some huge and difficult features the month long pauses imposed by release cycles are absolutely detrimental. Ideally they'd be developed outside the kernel until they are perfect, but Kent addresses this in his LWN comment: There is no funding/time to make that ideal scenario possible.

jethro_tell 1y ago
He could release a patch that can be pulled by the people that need it. If you’re using experimental file systems, I’d expect you to be pretty competent in being able to hold your own in a storage emergency, like compiling a kernel if that’s the way out. This is a made up emergency, to break the rules.
- eviks 1y ago
  The inconvenience of this process is also addressed by the dev, as is the different definition of experimental that you're using (though your expectation re kernel doesn't follow even without the mismatch in definitions)
  - rovr138 1y ago
    The kernel, even its bugs, should be stable (in that they shouldn't change unless it happens the correct way). If not, it starts introducing unexpected issues to users. If someone's testing against these versions, adding their fixes and patches, stuff like this will break things for users. He can't assume all users will be regular desktop users, even on an experimental area of the code. Things like 'RC' have meaning. Meaning that has been there for years. He can develop on a separate tree and users that want it can use it. This is used all over.
  - motorest 1y ago
    > The inconvenience of this process is also addressed by the dev, as is the different definition of experimental that you're using (...) The only aspect of "experimental" that matters is what it means to the release process. If you can't meet that bar then debating semantics won't help either. And by the way, the patch thread clearly stresses a) loss of data, b) the patch trying to sneak under the maintenance radar new features. That is the definition of unstable in anyone's book.
    - koverstreet 1y ago
      Experimental has no defined meaning with respect to the release process. It's a signal to users - "watch out if you're going to use this thing"
      - motorest 1y ago
        > Experimental has no defined meaning with respect to the release process. Nonsense. And to make matters worse, you're commenting as if trying to sneak features in bug fixes late on the release process has no impact on quality assurance.
- queenkjuul 1y ago
  Yeah the argument breaks down for me -- this project is so stable and mainstream, it's being used by a huge community of technically lay Linux users who can't boot a home built kernel temporarily to run a data recovery? And yet simultaneously, it's a bleeding edge experimental system that needs a license to break the Linux rules on account of its experimental nature? I just don't see how there's a critical mass of casual users that can't handle a complicated data recovery (as in, i won't generally believe this to be true, and if it is, those users should probably stick with something more mature), AND the system is still so experimental and developing so quickly that introducing features outside the merge window should be considered uncontroversial (or even necessary, as Kent seems to sometimes argue)
Analemma_ 1y ago
This position seems so incoherent. If it’s so experimental, why is it in the mainline kernel? And why are fixes so critical they can’t wait for a merge window? Who is using an “experimental” filesystem for mission-critical work that also has to be on untested bleeding-edge code? Like the sibling commenter, I suspect the word “experimental” is being used here to try and evade the rules that, somehow, every other part of the kernel manages to do just fine with.
- koverstreet 1y ago
  No, you have to understand that filesystems are massive (decade+) projects, and one of the key things you have to do with anything that big that has to work that perfectly is a very gradual rollout, starting with the more risk tolerant users and gradually increasing to a wider and wider set of users. We're very far along in that process now, but it's still marked as experimental because it is not quite ready for widespread deployment by just anyone. 6.16 is getting damn close, though. That means a lot of our users now are people getting it from distro kernels, who often have never compiled a kernel before - nevertheless, they can and do report bugs. And no matter where you are in the rollout, when you get bug reports you have to fix them and get the fixes out to users in a timely manner so that they can keep running, keep testing and reporting bugs. It's a big loss if a user has to wait 3 months for a bugfix - they'll get frustrated and leave, and a big part of what I do is building a community that knows how the system works, how to help debug, and how to report those bugs. A very common refrain I get is "it's experimental <expletive deleted>, why does it matter?" - and, well, the answer is getting fixes out in a timely manner matters just as much if not more if we want to get this thing done in a timely manner.
  - orbisvicis 1y ago
    Isn't this the point of DKMS, to decouple module code from kernel code?
    - koverstreet 1y ago
      Well, my hope when bcachefs was merged was for it to be a real kernel community project. At the time it looked like that could happen - there was real interest from Redhat prior to merging. Sadly Redhat's involvement never translated into much code, and while upstreaming did get me a large influx of users - many of which have helped enormously with the QA and stabilization effort - the drama and controversies have kept developers away, so on the whole it's meant more work, pressure and stress for me. So DKMS wouldn't be the worst route, at this point. It would be a real shame though, this close to taking the experimental label off, and an enormous hassle for users and distributions. But it's not my call to make, of course. I just write code...
motorest 1y ago
> That is a valid objection, but I still think that for some huge and difficult features the month long pauses imposed by release cycles are absolutely detrimental. I feel you're not answering the question, nor are you presenting any case in favor of forcing an exceptional release process for an unstable feature. The "detrimental" claim is also void of any reason or substance. It's not to it's users as users know better than rolling out experimental file systems for critical data, and those hypothetical users who somehow are really really interested in using bleeding edge will already be building their own kernel for this reason alone. Both scenarios don't require this code to be in the kernel, let alone exceptional release processes. > Ideally they'd be developed outside the kernel until they are perfect, but Kent addresses this in his LWN comment: There is no funding/time to make that ideal scenario possible. It is clear then that the code should be pulled from the kernel. If it isn't impossible to maintain a feature with the regular release process, everyone stands to benefit by not shipping code that is impossible to stabilize.
- bgwalter 1y ago
  > The "detrimental" claim is also void of any reason or substance. Thanks for the compliments! Detrimental for development speed, not for the users.

jethro_tell 1y ago

He could release a patch that can be pulled by the people that need it. If you’re using experimental file systems, I’d expect you to be pretty competent in being able to hold your own in a storage emergency, like compiling a kernel if that’s the way out. This is a made up emergency, to break the rules.

eviks 1y ago
The inconvenience of this process is also addressed by the dev, as is the different definition of experimental that you're using (though your expectation re kernel doesn't follow even without the mismatch in definitions)
- rovr138 1y ago
  The kernel, even its bugs, should be stable (in that they shouldn't change unless it happens the correct way). If not, it starts introducing unexpected issues to users. If someone's testing against these versions, adding their fixes and patches, stuff like this will break things for users. He can't assume all users will be regular desktop users, even on an experimental area of the code. Things like 'RC' have meaning. Meaning that has been there for years. He can develop on a separate tree and users that want it can use it. This is used all over.
- motorest 1y ago
  > The inconvenience of this process is also addressed by the dev, as is the different definition of experimental that you're using (...) The only aspect of "experimental" that matters is what it means to the release process. If you can't meet that bar then debating semantics won't help either. And by the way, the patch thread clearly stresses a) loss of data, b) the patch trying to sneak under the maintenance radar new features. That is the definition of unstable in anyone's book.
  - koverstreet 1y ago
    Experimental has no defined meaning with respect to the release process. It's a signal to users - "watch out if you're going to use this thing"
    - motorest 1y ago
      > Experimental has no defined meaning with respect to the release process. Nonsense. And to make matters worse, you're commenting as if trying to sneak features in bug fixes late on the release process has no impact on quality assurance.
queenkjuul 1y ago
Yeah the argument breaks down for me -- this project is so stable and mainstream, it's being used by a huge community of technically lay Linux users who can't boot a home built kernel temporarily to run a data recovery? And yet simultaneously, it's a bleeding edge experimental system that needs a license to break the Linux rules on account of its experimental nature? I just don't see how there's a critical mass of casual users that can't handle a complicated data recovery (as in, i won't generally believe this to be true, and if it is, those users should probably stick with something more mature), AND the system is still so experimental and developing so quickly that introducing features outside the merge window should be considered uncontroversial (or even necessary, as Kent seems to sometimes argue)

Analemma_ 1y ago

This position seems so incoherent. If it’s so experimental, why is it in the mainline kernel? And why are fixes so critical they can’t wait for a merge window? Who is using an “experimental” filesystem for mission-critical work that also has to be on untested bleeding-edge code? Like the sibling commenter, I suspect the word “experimental” is being used here to try and evade the rules that, somehow, every other part of the kernel manages to do just fine with.

koverstreet 1y ago
No, you have to understand that filesystems are massive (decade+) projects, and one of the key things you have to do with anything that big that has to work that perfectly is a very gradual rollout, starting with the more risk tolerant users and gradually increasing to a wider and wider set of users. We're very far along in that process now, but it's still marked as experimental because it is not quite ready for widespread deployment by just anyone. 6.16 is getting damn close, though. That means a lot of our users now are people getting it from distro kernels, who often have never compiled a kernel before - nevertheless, they can and do report bugs. And no matter where you are in the rollout, when you get bug reports you have to fix them and get the fixes out to users in a timely manner so that they can keep running, keep testing and reporting bugs. It's a big loss if a user has to wait 3 months for a bugfix - they'll get frustrated and leave, and a big part of what I do is building a community that knows how the system works, how to help debug, and how to report those bugs. A very common refrain I get is "it's experimental <expletive deleted>, why does it matter?" - and, well, the answer is getting fixes out in a timely manner matters just as much if not more if we want to get this thing done in a timely manner.
- orbisvicis 1y ago
  Isn't this the point of DKMS, to decouple module code from kernel code?
  - koverstreet 1y ago
    Well, my hope when bcachefs was merged was for it to be a real kernel community project. At the time it looked like that could happen - there was real interest from Redhat prior to merging. Sadly Redhat's involvement never translated into much code, and while upstreaming did get me a large influx of users - many of which have helped enormously with the QA and stabilization effort - the drama and controversies have kept developers away, so on the whole it's meant more work, pressure and stress for me. So DKMS wouldn't be the worst route, at this point. It would be a real shame though, this close to taking the experimental label off, and an enormous hassle for users and distributions. But it's not my call to make, of course. I just write code...

motorest 1y ago

> That is a valid objection, but I still think that for some huge and difficult features the month long pauses imposed by release cycles are absolutely detrimental. I feel you're not answering the question, nor are you presenting any case in favor of forcing an exceptional release process for an unstable feature. The "detrimental" claim is also void of any reason or substance. It's not to it's users as users know better than rolling out experimental file systems for critical data, and those hypothetical users who somehow are really really interested in using bleeding edge will already be building their own kernel for this reason alone. Both scenarios don't require this code to be in the kernel, let alone exceptional release processes. > Ideally they'd be developed outside the kernel until they are perfect, but Kent addresses this in his LWN comment: There is no funding/time to make that ideal scenario possible. It is clear then that the code should be pulled from the kernel. If it isn't impossible to maintain a feature with the regular release process, everyone stands to benefit by not shipping code that is impossible to stabilize.

bgwalter 1y ago
> The "detrimental" claim is also void of any reason or substance. Thanks for the compliments! Detrimental for development speed, not for the users.