3 ms·

All I need to support bcachefs is for the same rules to apply as they are to every other subsystem.

• magicalhippo 1y ago
  From what I have read and recall, the same rules do apply. Rather, the disagreement seems to be over what constitutes a feature and what constitutes a bugfix. As I recall, your view is that the repair code is part of the bugfix. However Linus deems it a feature, and thus applied the "no new features outside the merge window" rule. I think Linus is correct here and you are wrong. New code made to repair flaws that previously could not be repaired is definitely a new feature of the repair tool. On the other hand, I am sympathetic to your argument that this is after all an experimental filesystem which has different needs from a stable hardware driver say, and as I recall the repair tool changes were entirely contained in the bcachefs subtree. As such, the worst it could do was to fail compilation on certain platforms, which already happened previously. Personally I would have dropped the bugfix vs feature debate and focused on trying to get Linus to allow the repair code in as a new feature. From what I recall Linus said, you already burned some goodwill by the previous kernel compilation failure, but perhaps Linus could change his stance if you worked with him.
  • koverstreet 1y ago
    New features go in during RCs all the time. The hard rule you're thinking of doesn't exist, it's all risk vs. reward.
    • ekaryotic 1y ago
      If you had requested your code be rolled back to an earlier stable version as an alternative way of fixing the bug rather than merging unstable code you may have come to a compromise.