3 ms·

I'm not sure how I feel on the larger picture, but I think I understand his view of why certain PRs aren't the place to talk about certain things. It's because

I'm not sure how I feel on the larger picture, but I think I understand his view of why certain PRs aren't the place to talk about certain things. It's because he views user data integrity as a more critical concern than the PR process or team dynamics - which, as a user, I don't fault him for. I think that in his mind, every hour/day/week spent debating things on a PR equals more people losing or corrupting data. This is not commonly the case with most PRs - it's specific to popular filesystems in active development. What I don't necessarily buy is how to weigh this responsibility against the responsibility users take on when they use such an experimental FS in the first place. It's a tough question in my mind, and both sides have good points. And I also don't know anything about the relative safety vs. severity of each patch. But what I do understand is the motivation for not viewing these as generic PRs against generic codebases. So the idea that this is a red flag in this case just doesn't seem right to me, based on my current understanding.

koverstreet 1y ago
No, it's mainly that tensions have been high between myself and Linus so I want that stuff done privately so it doesn't spill out into the community the way it has been :) It gets to be a real distraction. Fortunately the people I work with have learned how to roll with it, so it's not nearly as bad as it used to be. Now it mainly shows up in forum comments where it doesn't really affect me and I can eat popcorn. It is true that I don't want critical fixes being held up by angry arguing, but most pull requests, even fixes, aren't nearly so critical. The main thing I keep hammering on is "the development process _matters_ if we want to get this done right", and user considerations are a big part of that. Debugging issues that come up in the wild, and getting those fixes to users in a timely manner so they can keep testing and we can get all these crazy failure modes sorted out is a big part of that - if we want a filesystem that's truly bulletproof. I know I want that! I've been spending the past week and a half mostly working with one user and his filesystem that's been through flaky dying controllers and now lightning strikes; ext4 even got corrupted on the same setup. But we discovered some 6.16 regressions, got some more people involved staring at code and logs (a new guy spotted a big one), and another small pile of fixes are going out next week. And even with the 6.16 regressions (some nasty ones were found), it's looking like he didn't lose much, thanks in part to journal rewind. This thing is turning into a tank. All in a day's work...
- dastbe 1y ago
  As a person who probably has one of the best vantage points on this, how was Apple to get apfs out so quickly compared to filesystems in Linux like bcachefs?
  - koverstreet 1y ago
    I am curious about that myself, I know very little about apfs. But Apple has historically been strong on organizing and supporting teams (see: their chip design), a filesystem sounds exactly like something they'd do well if they decided to give it the proper investment and support. Where they seem to be falling down these days is software maintenance - many, many reports of MacOS getting buggier with every release. But a big, complicated, but well defined and self contained engineering project? That's their ballpark.
  - plorkyeran 1y ago
    APFS was the third filesystem designed by Dominic Giampaolo and fourth that he'd worked on, had a full team working on it, and had absurd testing resources thrown at it. It was set up to succeed in every way that a software project can be.

koverstreet 1y ago

No, it's mainly that tensions have been high between myself and Linus so I want that stuff done privately so it doesn't spill out into the community the way it has been :) It gets to be a real distraction. Fortunately the people I work with have learned how to roll with it, so it's not nearly as bad as it used to be. Now it mainly shows up in forum comments where it doesn't really affect me and I can eat popcorn. It is true that I don't want critical fixes being held up by angry arguing, but most pull requests, even fixes, aren't nearly so critical. The main thing I keep hammering on is "the development process _matters_ if we want to get this done right", and user considerations are a big part of that. Debugging issues that come up in the wild, and getting those fixes to users in a timely manner so they can keep testing and we can get all these crazy failure modes sorted out is a big part of that - if we want a filesystem that's truly bulletproof. I know I want that! I've been spending the past week and a half mostly working with one user and his filesystem that's been through flaky dying controllers and now lightning strikes; ext4 even got corrupted on the same setup. But we discovered some 6.16 regressions, got some more people involved staring at code and logs (a new guy spotted a big one), and another small pile of fixes are going out next week. And even with the 6.16 regressions (some nasty ones were found), it's looking like he didn't lose much, thanks in part to journal rewind. This thing is turning into a tank. All in a day's work...

dastbe 1y ago
As a person who probably has one of the best vantage points on this, how was Apple to get apfs out so quickly compared to filesystems in Linux like bcachefs?
- koverstreet 1y ago
  I am curious about that myself, I know very little about apfs. But Apple has historically been strong on organizing and supporting teams (see: their chip design), a filesystem sounds exactly like something they'd do well if they decided to give it the proper investment and support. Where they seem to be falling down these days is software maintenance - many, many reports of MacOS getting buggier with every release. But a big, complicated, but well defined and self contained engineering project? That's their ballpark.
- plorkyeran 1y ago
  APFS was the third filesystem designed by Dominic Giampaolo and fourth that he'd worked on, had a full team working on it, and had absurd testing resources thrown at it. It was set up to succeed in every way that a software project can be.