5 ms·

I need to write up a proper patreon post on all this stuff, because there's a lot of misinformation going around. No, I was not "ignoring the merge window". Li

I need to write up a proper patreon post on all this stuff, because there's a lot of misinformation going around. No, I was not "ignoring the merge window". Linus was trying to make and dictate calls on what is and is not a critical bugfix, and with a filesystem eating bug we needed to respond to, that was an unacceptable situation.

1oooqooq 1y ago
this crowd is wild. the author answer is voted down :) edit: by the time i commented it was already dark text. guess it recovered.
- khimaros 1y ago
  if you read the LKML archives closely, you'll find this sort of reply from koverstreet (deflecting all responsibility while taking none) as typical as it is deeply misguided.
  - koverstreet 1y ago
    Just looking for somewhere to stick that pitchfork, eh?
    - khimaros 1y ago
      this was my first time speaking publicly about my opinion on this after reading as much of the history as i could with an open mind. i was really looking forward to bcachefs landing in the mainline kernel because btrfs doesn't meet my needs. i was and still am rooting for you, but your social skills really are comically bad and it's impacting the potential of the project. it makes me sad. P.S. your response here doesn't surprise me at all and is completely in character based on everything else i've seen from you.
repstosb 1y ago
Finding defects is a good thing, and fixing defects is a good thing. Adding new features can be a good thing as long as it doesn't introduce or uncover too many new defects in previously stable code. But what is lacking in your development process that you keep finding "critical" defects that could affect a large number of users during the merge window? It seems like bcachefs would benefit from parallel development spirals, where unproven code is guarded by experimental flags and recommended only for users who are prepared to monitor and apply patches outside of the main kernel release cycle, while the default configuration of the mainline version goes through a more thorough test and validation process and more rarely sees "surprise" breakage. It certainly appears that Linus can't tell the difference between your new feature introductions and your maintenance fixes, and that should trigger some self-reflection. He clearly couldn't let all of the thousands of different kernel components operate in the style you seem to prefer for bacachefs.
- koverstreet 1y ago
  > It seems like bcachefs would benefit from parallel development spirals, where unproven code is guarded by experimental flags and recommended only for users who are prepared to monitor and apply patches outside of the main kernel release cycle, while the default configuration of the mainline version goes through a more thorough test and validation process and more rarely sees "surprise" breakage. Maybe if you're a distance observer who isn't otherwise participating in the project What's the saying about too many cooks in the kitchen? These concerns aren't coming from the people who are actually using it. They're coming from people who are accustomed to the old ways of doing things and have no idea what working closely with modern test infrastructure is like. There wasn't anything unusual about the out-of-merge-window patches I was sending Linus except for volume, which is exactly what you'd expect in a rapidly stabilizing filesystem. If anything I've been more conservative about what I send that other subsystems. > It certainly appears that Linus can't tell the difference between your new feature introductions and your maintenance fixes, and that should trigger some self-reflection. He clearly couldn't let all of the thousands of different kernel components operate in the style you seem to prefer for bacachefs. If Linus can't figure out which subsystems have QA problems and which don't, that's his problem, not mine.
bagxrvxpepzn 1y ago
> Linus was trying to make and dictate calls on what is and is not a critical bugfix, and with a filesystem eating bug we needed to respond to, that was an unacceptable situation. That's literally his job?
- koverstreet 1y ago
  His job is to create drama, and argue over things that don't need to be argued? Linus has never once found a mistake in the bcachefs pull requests, but he has created massive headaches for getting bugfixes out to users that were waiting on them.

1oooqooq 1y ago

this crowd is wild. the author answer is voted down :) edit: by the time i commented it was already dark text. guess it recovered.

khimaros 1y ago
if you read the LKML archives closely, you'll find this sort of reply from koverstreet (deflecting all responsibility while taking none) as typical as it is deeply misguided.
- koverstreet 1y ago
  Just looking for somewhere to stick that pitchfork, eh?
  - khimaros 1y ago
    this was my first time speaking publicly about my opinion on this after reading as much of the history as i could with an open mind. i was really looking forward to bcachefs landing in the mainline kernel because btrfs doesn't meet my needs. i was and still am rooting for you, but your social skills really are comically bad and it's impacting the potential of the project. it makes me sad. P.S. your response here doesn't surprise me at all and is completely in character based on everything else i've seen from you.

repstosb 1y ago

Finding defects is a good thing, and fixing defects is a good thing. Adding new features can be a good thing as long as it doesn't introduce or uncover too many new defects in previously stable code. But what is lacking in your development process that you keep finding "critical" defects that could affect a large number of users during the merge window? It seems like bcachefs would benefit from parallel development spirals, where unproven code is guarded by experimental flags and recommended only for users who are prepared to monitor and apply patches outside of the main kernel release cycle, while the default configuration of the mainline version goes through a more thorough test and validation process and more rarely sees "surprise" breakage. It certainly appears that Linus can't tell the difference between your new feature introductions and your maintenance fixes, and that should trigger some self-reflection. He clearly couldn't let all of the thousands of different kernel components operate in the style you seem to prefer for bacachefs.

koverstreet 1y ago
> It seems like bcachefs would benefit from parallel development spirals, where unproven code is guarded by experimental flags and recommended only for users who are prepared to monitor and apply patches outside of the main kernel release cycle, while the default configuration of the mainline version goes through a more thorough test and validation process and more rarely sees "surprise" breakage. Maybe if you're a distance observer who isn't otherwise participating in the project What's the saying about too many cooks in the kitchen? These concerns aren't coming from the people who are actually using it. They're coming from people who are accustomed to the old ways of doing things and have no idea what working closely with modern test infrastructure is like. There wasn't anything unusual about the out-of-merge-window patches I was sending Linus except for volume, which is exactly what you'd expect in a rapidly stabilizing filesystem. If anything I've been more conservative about what I send that other subsystems. > It certainly appears that Linus can't tell the difference between your new feature introductions and your maintenance fixes, and that should trigger some self-reflection. He clearly couldn't let all of the thousands of different kernel components operate in the style you seem to prefer for bacachefs. If Linus can't figure out which subsystems have QA problems and which don't, that's his problem, not mine.

bagxrvxpepzn 1y ago

> Linus was trying to make and dictate calls on what is and is not a critical bugfix, and with a filesystem eating bug we needed to respond to, that was an unacceptable situation. That's literally his job?

koverstreet 1y ago
His job is to create drama, and argue over things that don't need to be argued? Linus has never once found a mistake in the bcachefs pull requests, but he has created massive headaches for getting bugfixes out to users that were waiting on them.