> On 2024-10-20 9:59 AM PDT Kent Overstreet <[email protected]> wrote:
> ... > I have a lot of users and testers that I work with, and will bend over > backwards for if something is broken, and to make sure data isn't lost. Absolutely. We've all seen you do that over the years. That's a big part of the reason why users like me spend so much of our own time and resources testing and supporting your work. > But I do draw a line at being demanding, or all the "constructive > criticism" that comes with an attitude of "I know your job better than > you do". And I'm not doing that. I'm simply reporting bugs and offering perspectives that you may not have thought of for your consideration. I don't demand that you do anything because I **can't** demand that you do anything. I'll give you an example. More than a year ago I raised the issue that bcachefs does not allow multiple versions/images of a filesystem to be mounted at the same time. I pointed out that there are several professional workflows that require this (forensics, auditing, etc) and non-professional workflows too (retrieving a previous version of a file from an LVM snapshot, etc). I pointed out that other modern filesystems allow it and argued that it is a needed feature. You disagreed that it is that important and have never (to date) implemented the feature. This causes me to have to create special-case workarounds specific to bcachefs which operate differently than what I do for every other filesystem. Despite this extra work and inconvenience for me I have never brought it up again, never nagged you and never demanded that you listen to me and change your mind. I made my pitch, you made your decision and I accept your decision even if I don't like it. I give you my opinion and the logic behind it and you can choose to consider what I say or not. You have your decades of experience. I have my decades of experience. Despite my own considerable experience I've personally found that sometimes other people **can** make persuasive points that change my mind and can make a project better **if I'm open to them**. It's really, really hard to tell what someone's attitude is over the internet. I'm sometimes guilty of trying to do that too and so in the cases where I've done that to you I apologize. But I assure you my intent when I make a comment is to **persuade** you and not to demand or force you to do anything. > You wouldn't walk into someone's office and immediately start > telling them how to do things, would you? No, but that's an orthogonal argument. This isn't an office. This (the Linux kernel) is an open-source project that not only encourages open collaboration among many types of people **it absolutely requires it**. By most any objective measure Linux has been, still is and will continue to be by far the most successful, influential and dominant software project in the history of humanity and it's not even close. In my opinion that's a core reason why it rubs a lot of people the wrong way when you over and over seem to tell Linus and the other kernel developers "you're doing it wrong." (If I'm misinterpreting I apologize.) Now, you've definitely earned the right to voice your opinion but I'd advise taking a page from my book and making your point as eloquently as you can **once** and then let it go if they don't go for all of it. If you must, bring it up again periodically (I'd suggest annually) but of course that's just free advice (and worth every penny!) and you should do what you th ink is best in the way you think is best. I'll also make the self-serving point that Linux isn't successfully only because of kernel developers like you it's just as much due to users like me. Back in the 90s I was once **literally** laughed out of a boardroom for presenting rationale for why my company should pivot from developing products on traditional Unices and start focusing our efforts on the new Linux thing. They disagreed; I left the company and within months they were out of business so I guess I got the last laugh. I didn't write fancy papers and become famous the way some people did back then but I have ever since relentlessly done my part by pushing every company I've worked for to be more successful by more fully leveraging the benefits of Linux. Now, of course, pretty much every company gets it. I advocate for Linux in my personal life too. And there are countless millions of other users who also contribute in their own ways big and small most of whom will never be known or even have conversations on kernel ma iling lists but who are just as important and integral to the success of Linux. So there's a whole big picture thing to keep in mind. > I don't suscribe to the modern theories about how we all have to be nice > to each other and always use nice words Well those theories are not at all modern concepts. Whether you call it karma, or the Golden Rule, or being neighborly, or modern political correctness, the idea that human societies work better when people work together and politely respect others' differences and opinions is ancient. Now as a practical matter all human beings have egos and feelings. You could make an interesting theoretical logical argument that those things **shouldn't** matter in social interactions such as the development of software but my experience is that in reality those things matter **more than everything else** in **every** type of voluntary social interaction. One of the first hard lessons I learned in independent life is that it doesn't matter how smart you are if you can't get people to like you. If a large enough portion of the people around you don't like you they will keep sniping at you until you are (socially or professionally) dead. That's just a fact of life that's also true professionally and it's probably true here too. Should it be that way? The answer doesn't matter. For me, dealing with it professionally was initially an intellectual challenge; how do I get my coworkers to like me so that I (and my ideas) can be more successful? But the funny thing is I found out that purposefully expending effort to be nice so I can further my own success doesn't just make **me** more successful, it makes everyone else more successful too. And it has the unexpected benefit of making me **happier** too, which is something I need. So while I understand your opinion it's not one I share. > ... > But you're complaining about an EOL kernel, where the issues have long > been fixed, so in this case there's just not a lot I can do. I could ask > Greg to cut a new 6.9 release, but all the distros have been told that > 6.9 is EOL so it's not likely it would be widely deployed. I am **not** complaining about an EOL kernel. I explicitly stated that I **didn't** need a fix. I simply reported a bug that affected me which I was unaware had been fixed. I do think that if you find and fix a bug like that it would be nice for you to document it and let users know about it so we can possibly avoid wasting a lot of our time and effort unnecessarily. > ... > The ability to upgrade to a new on disk format, and then seamlessly > downgrade - that hasn't been done before, keep that in mind, and that's > an enormously useful capability that makes it dramatically _less_ risky > to deploy new features. As I said previously I understand and accept your reasoning here. I think it's risky to believe you can ahead of time code in the ability to understand and correctly revert any possible format change you'll come up with in the future especially since the only reason we're talking about it is because it's already failed at least once. It's also a system that I believe can't be meaningfully tested without a time machine. But it's your project and I accept your judgement and I have no need to talk about that feature any further (unless you yourself find it helpful to continue the discussion). Thanks, Carl
