4 ms·

> It seems like bcachefs would benefit from parallel development spirals, where unproven code is guarded by experimental flags and recommended only for users wh

> 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.

wizzwizz4 1y ago
Concerns about general policy need to be handled separately from individual cases. You needed to play along, advocate for your position, explain your position (e.g. demonstrate how your processes eliminate certain classes of errors; or find some objective way to measure QA problems and present the stats), and push for a holistic process change that supports your use-case. That process change would need input from other people, and might end up very different to your original proposal, but it could have happened. Instead, you've burned (and continue to burn) bridges. Linus's job is not to make the very next version of the kernel as good as it can be. It's to keep the whole system of Linux kernel maintenance going. (Maintaining the quality of the next version is almost a side-effect.) Asking him to make frequent exceptions to process is the equivalent of going "this filesystem is making poor decisions: let's hex-edit /dev/sda to allocate the blocks better". Your priority is making the next version of bcachefs as good as it can be, and you're confident that merging your patchsets won't break the kernel, but that's entirely irrelevant. > If Linus can't figure out which subsystems have QA problems and which don't, that's his problem, not mine. You have missed the point by a mile.
- koverstreet 1y ago
  > Concerns about general policy need to be handled separately from individual cases. Citation needed. > Linus's job is not to make the very next version of the kernel as good as it can be. It's to keep the whole system of Linux kernel maintenance going. (Maintaining the quality of the next version is almost a side-effect.) Asking him to make frequent exceptions to process is the equivalent of going "this filesystem is making poor decisions You're arguing from a false premise here. No exceptions were needed or required, bcachefs was being singled out because he and the other maintainers involved had no real interest in the end goal of getting a stable, reliable, trustworthy modern filesystem. The discussions, public and private - just like you're doing here - always managed to veer away from engineering concerns; people were more concerned with politics, "playing the game", and - I'm not joking here - undermining me as maintainer; demanding for someone else to take over. Basic stuff like QA procedure and how we prioritize patches never entered into it, even as I repeatedly laid that stuff out. > > If Linus can't figure out which subsystems have QA problems and which don't, that's his problem, not mine. > You have missed the point by a mile. No, that is very much the point here. bcachefs has always had one of the better track records at avoiding regressions and quickly handling them when they do get through, and was being singled out as if something was going horribly awry anyways. That needs an explanation, but one was never given. Look, from the way you've been arguing things - have you been getting your background from youtube commentators? You have a pretty one sided take, and you're pushing that point of view really hard when talking to the person who's actually been in the middle of it for the past two years. Maybe you should reevaluate that.
  - wizzwizz4 1y ago
    Bureaucracies run on process. You call that "politics", but (when arguing with programmers) I call it code. The Linux kernel project is a bureaucracy. > citation needed I'm sure you're familiar with "separation of concerns" in programming: it's the same principle. My experience of bureaucracies is experience, but I'm sure most good books on the topic will have a paragraph or chapter on this. > bcachefs was being singled out because he and the other maintainers involved had no real interest in the end goal of getting a stable, reliable, trustworthy modern filesystem. I imagine they would dispute that. > No exceptions were needed or required, I know that Linus Torvalds would dispute that. In this HN thread and elsewhere, you've made good arguments that treating your approach as an exception is not warranted, and that your approach is better, but you surely aren't claiming that your approach is the usual approach for kernel development? > undermining me as maintainer Part of the job is dealing with Linus Torvalds. You're not good at that. It would make sense for you to focus on architecture, programming, making bcachefs great, and to let someone else deal with submitting patches to the kernel, or arguing those technical arguments where you're right, but aren't getting listened to. People are "more concerned with politics" than with engineering concerns because the problem is not with your engineering. > bcachefs has always had one of the better track records at avoiding regressions and quickly handling them when they do get through That's not relevant. I know that you don't see that it's not relevant: that's why I'm saying it's not relevant. > have you been getting your background from youtube commentators? No, but I'm used to disputes of this nature, and I'm used to dealing with unreasonable people. You believe that others are being unreasonable, but you're not following an effective strategy for dealing with unreasonable people. I am attempting to give advice, because I want bcachefs in the kernel, and I haven't a hope of changing Linus Torvalds' mind, but I have half a hope of changing yours. Rule one of dealing with unreasonable people is to pick your battles. How many times have I said "dispute" or "argument" in this comment? How many times have these been worthy disputes? Even if I've completely mischaracterised the overall situation, surely you can't claim that every argument you've had on the LKML or in LWN comments has been worth bcachefs being removed from the kernel.

wizzwizz4 1y ago

Concerns about general policy need to be handled separately from individual cases. You needed to play along, advocate for your position, explain your position (e.g. demonstrate how your processes eliminate certain classes of errors; or find some objective way to measure QA problems and present the stats), and push for a holistic process change that supports your use-case. That process change would need input from other people, and might end up very different to your original proposal, but it could have happened. Instead, you've burned (and continue to burn) bridges. Linus's job is not to make the very next version of the kernel as good as it can be. It's to keep the whole system of Linux kernel maintenance going. (Maintaining the quality of the next version is almost a side-effect.) Asking him to make frequent exceptions to process is the equivalent of going "this filesystem is making poor decisions: let's hex-edit /dev/sda to allocate the blocks better". Your priority is making the next version of bcachefs as good as it can be, and you're confident that merging your patchsets won't break the kernel, but that's entirely irrelevant. > If Linus can't figure out which subsystems have QA problems and which don't, that's his problem, not mine. You have missed the point by a mile.

koverstreet 1y ago
> Concerns about general policy need to be handled separately from individual cases. Citation needed. > Linus's job is not to make the very next version of the kernel as good as it can be. It's to keep the whole system of Linux kernel maintenance going. (Maintaining the quality of the next version is almost a side-effect.) Asking him to make frequent exceptions to process is the equivalent of going "this filesystem is making poor decisions You're arguing from a false premise here. No exceptions were needed or required, bcachefs was being singled out because he and the other maintainers involved had no real interest in the end goal of getting a stable, reliable, trustworthy modern filesystem. The discussions, public and private - just like you're doing here - always managed to veer away from engineering concerns; people were more concerned with politics, "playing the game", and - I'm not joking here - undermining me as maintainer; demanding for someone else to take over. Basic stuff like QA procedure and how we prioritize patches never entered into it, even as I repeatedly laid that stuff out. > > If Linus can't figure out which subsystems have QA problems and which don't, that's his problem, not mine. > You have missed the point by a mile. No, that is very much the point here. bcachefs has always had one of the better track records at avoiding regressions and quickly handling them when they do get through, and was being singled out as if something was going horribly awry anyways. That needs an explanation, but one was never given. Look, from the way you've been arguing things - have you been getting your background from youtube commentators? You have a pretty one sided take, and you're pushing that point of view really hard when talking to the person who's actually been in the middle of it for the past two years. Maybe you should reevaluate that.
- wizzwizz4 1y ago
  Bureaucracies run on process. You call that "politics", but (when arguing with programmers) I call it code. The Linux kernel project is a bureaucracy. > citation needed I'm sure you're familiar with "separation of concerns" in programming: it's the same principle. My experience of bureaucracies is experience, but I'm sure most good books on the topic will have a paragraph or chapter on this. > bcachefs was being singled out because he and the other maintainers involved had no real interest in the end goal of getting a stable, reliable, trustworthy modern filesystem. I imagine they would dispute that. > No exceptions were needed or required, I know that Linus Torvalds would dispute that. In this HN thread and elsewhere, you've made good arguments that treating your approach as an exception is not warranted, and that your approach is better, but you surely aren't claiming that your approach is the usual approach for kernel development? > undermining me as maintainer Part of the job is dealing with Linus Torvalds. You're not good at that. It would make sense for you to focus on architecture, programming, making bcachefs great, and to let someone else deal with submitting patches to the kernel, or arguing those technical arguments where you're right, but aren't getting listened to. People are "more concerned with politics" than with engineering concerns because the problem is not with your engineering. > bcachefs has always had one of the better track records at avoiding regressions and quickly handling them when they do get through That's not relevant. I know that you don't see that it's not relevant: that's why I'm saying it's not relevant. > have you been getting your background from youtube commentators? No, but I'm used to disputes of this nature, and I'm used to dealing with unreasonable people. You believe that others are being unreasonable, but you're not following an effective strategy for dealing with unreasonable people. I am attempting to give advice, because I want bcachefs in the kernel, and I haven't a hope of changing Linus Torvalds' mind, but I have half a hope of changing yours. Rule one of dealing with unreasonable people is to pick your battles. How many times have I said "dispute" or "argument" in this comment? How many times have these been worthy disputes? Even if I've completely mischaracterised the overall situation, surely you can't claim that every argument you've had on the LKML or in LWN comments has been worth bcachefs being removed from the kernel.