4 ms·

Linus T is responsible for everything in Linux, it is his project and he is the maintainer. He can do everything he wants in his branch and people just have to

by tuna74 1y ago

Linus T is responsible for everything in Linux, it is his project and he is the maintainer. He can do everything he wants in his branch and people just have to accept it. If you want to be responsible you have to fork Linux.

koverstreet 1y ago
Let's examine this, shall we? Has he ever even been involved with a bcachefs bug? No, aside from arguing against shipping bugfixes. Has he contributed in any way, besides merging code? No... Has he set rules or guidelines that benefited bcachefs reliability? No, but he has shouted down talk about automated testing. I think you're confusing power with responsibility.
- immibis 1y ago
  You're still doing that thing where you assume everyone else is you. Linus's job (some of which he delegates) is to take the contributions from ALL the hundreds of maintainers, and bundle it into a unified coherent whole. He is not only responsible for bcachefs reliability. In the train analogy I already used, he is the train driver, he is responsible for getting everyone who is on the train to their destination, but he is not responsible for ensuring that you're on the train. It's your responsibility to ensure that you're on the train when it departs. You are one of those maintainers (not any more). Your code can be taken into the bundle (not any more), but on the bundle's schedule, not yours. You have consistently failed to understand that the train doesn't wait for you - if you are late, you get on the next one. If you don't want to get on the next one, then don't be late. Normal people, after missing a train once or twice, would adjust their schedule accordingly so they won't miss it next time. But your exclusive, repeated reaction has been to yell at the train driver and the station master, which is why you've been kicked out of the station. Have you ever ridden a train, by the way? Were you on time? (Deutsche Bahn doesn't count because they're not on time)
  - koverstreet 1y ago
    We're not talking about situations where the bcachefs changes could plausibly affect the rest of the kernel, and I am well known even within the kernel community for being on top of potential issues and responsive on bugs.
    - immibis 1y ago
      The merge window policy is not limited to cases where the new bcachefs features affect the rest of the kernel.
      - bcrl 1y ago
        Read the following commit log: Pull btrfs fixes from David Sterba: "Several zoned mode fixes, mount option printing fixups, folio state handling fixes and one log replay fix. - zoned mode: - zone activation and finish fixes - block group reservation fixes - mount option fixes: - bring back printing of mount options with key=value that got accidentally dropped during mount option parsing in 6.8 - fix inverse logic or typos when printing nodatasum/nodatacow - folio status fixes: - writeback fixes in zoned mode - properly reset dirty/writeback if submission fails - properly handle TOWRITE xarray mark/tag - do not set mtime/ctime to current time when unlinking for log replay" Sounds like they added a feature back in that was removed 10 major releases ago. Why is that not considered a feature? By this logic that btrfs merge request should have been rejected. The "feature" label is messy. If the "feature" means that a user doesn't lose their data in a filesystem, is it really a "feature" or is it a bug fix? It's very much shades of grey. What a lot of people are missing here is that bcachefs has a lot of test cases for regressions that are run as part of Kent's continuous integration infrastructure. A lot of Linux filesystems do not have this kind of easy regression testing, in part because this kind of testing is easiest when you do it as part of development, but very difficult to achieve any scale of coverage if it's done after the fact. The older the code is in Linux, the more likely it is that it tends to get coverage via the stress tests and intregration tests that various folks run on kernel releases. But such tests are not regression tests for data structures, I/O failures, corrupted data... So much of what is going on is bikeshedding the process of submitting changes. It would be far more productive for people to look at the process Kent follows during development, and to then make educated comments about the code that arises from that process. Good developers know the value of tests. Great developers know that improving your test coverage with every bit of new development means you can develop faster over the long run by not getting bogged down by silent regressions. Edit: I do have to shout out to the XFS folks. xfstests is a huge contributor to the improvement of Linux filesystems over the last few decades.

by tuna74 1y ago

koverstreet 1y ago

Let's examine this, shall we? Has he ever even been involved with a bcachefs bug? No, aside from arguing against shipping bugfixes. Has he contributed in any way, besides merging code? No... Has he set rules or guidelines that benefited bcachefs reliability? No, but he has shouted down talk about automated testing. I think you're confusing power with responsibility.

immibis 1y ago
You're still doing that thing where you assume everyone else is you. Linus's job (some of which he delegates) is to take the contributions from ALL the hundreds of maintainers, and bundle it into a unified coherent whole. He is not only responsible for bcachefs reliability. In the train analogy I already used, he is the train driver, he is responsible for getting everyone who is on the train to their destination, but he is not responsible for ensuring that you're on the train. It's your responsibility to ensure that you're on the train when it departs. You are one of those maintainers (not any more). Your code can be taken into the bundle (not any more), but on the bundle's schedule, not yours. You have consistently failed to understand that the train doesn't wait for you - if you are late, you get on the next one. If you don't want to get on the next one, then don't be late. Normal people, after missing a train once or twice, would adjust their schedule accordingly so they won't miss it next time. But your exclusive, repeated reaction has been to yell at the train driver and the station master, which is why you've been kicked out of the station. Have you ever ridden a train, by the way? Were you on time? (Deutsche Bahn doesn't count because they're not on time)
- koverstreet 1y ago
  We're not talking about situations where the bcachefs changes could plausibly affect the rest of the kernel, and I am well known even within the kernel community for being on top of potential issues and responsive on bugs.
  - immibis 1y ago
    The merge window policy is not limited to cases where the new bcachefs features affect the rest of the kernel.
    - bcrl 1y ago
      Read the following commit log: Pull btrfs fixes from David Sterba: "Several zoned mode fixes, mount option printing fixups, folio state handling fixes and one log replay fix. - zoned mode: - zone activation and finish fixes - block group reservation fixes - mount option fixes: - bring back printing of mount options with key=value that got accidentally dropped during mount option parsing in 6.8 - fix inverse logic or typos when printing nodatasum/nodatacow - folio status fixes: - writeback fixes in zoned mode - properly reset dirty/writeback if submission fails - properly handle TOWRITE xarray mark/tag - do not set mtime/ctime to current time when unlinking for log replay" Sounds like they added a feature back in that was removed 10 major releases ago. Why is that not considered a feature? By this logic that btrfs merge request should have been rejected. The "feature" label is messy. If the "feature" means that a user doesn't lose their data in a filesystem, is it really a "feature" or is it a bug fix? It's very much shades of grey. What a lot of people are missing here is that bcachefs has a lot of test cases for regressions that are run as part of Kent's continuous integration infrastructure. A lot of Linux filesystems do not have this kind of easy regression testing, in part because this kind of testing is easiest when you do it as part of development, but very difficult to achieve any scale of coverage if it's done after the fact. The older the code is in Linux, the more likely it is that it tends to get coverage via the stress tests and intregration tests that various folks run on kernel releases. But such tests are not regression tests for data structures, I/O failures, corrupted data... So much of what is going on is bikeshedding the process of submitting changes. It would be far more productive for people to look at the process Kent follows during development, and to then make educated comments about the code that arises from that process. Good developers know the value of tests. Great developers know that improving your test coverage with every bit of new development means you can develop faster over the long run by not getting bogged down by silent regressions. Edit: I do have to shout out to the XFS folks. xfstests is a huge contributor to the improvement of Linux filesystems over the last few decades.