>>>>> "Kent" == Kent Overstreet <kent.overstreet@xxxxxxxxx> writes: I wasn't sure if I wanted to chime in here, or even if it would be worth it. But whatever. > On Thu, Jun 26, 2025 at 08:21:23PM -0700, Linus Torvalds wrote: >> On Thu, 26 Jun 2025 at 19:23, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: >> > >> > per the maintainer thread discussion and precedent in xfs and btrfs >> > for repair code in RCs, journal_rewind is again included >> >> I have pulled this, but also as per that discussion, I think we'll be >> parting ways in the 6.17 merge window. >> >> You made it very clear that I can't even question any bug-fixes and I >> should just pull anything and everything. > Linus, I'm not trying to say you can't have any say in bcachefs. Not at > all. > I positively enjoy working with you - when you're not being a dick, > but you can be genuinely impossible sometimes. A lot of times... Kent, you can be a dick too. Prime example, the lines above. And how you've treated me and others who gave feedback on bcachefs in the past. I'm not a programmer, I'm in IT and follow this because it's interesting, and I've been doing data management all my career. So new filesystems are interesting. But I've also been bitten by data loss, so I'd never ever trust my production data to something labeled "experimental". It's wonderful that you have stepped up and managed to get back people's data when bugs in the code have caused them to lose data. But for god's sake, just because you can find and fix this type of bug during the -rc series, doesn't mean you need to try and patch it NOW. Queue it up for the next release. Tell people how they can pull the patch early if they want, but don't push it late in the release cycle. I've been watching this list since the early 2.x days, and I've seen how the workflow has evolved over time. I've watched people burn out and leave, flame wars and all kinds of crap. And the people who have stayed around are generally the nice people. The flexible people. The people who know when to back the f*ck off and take their time. > When bcachefs was getting merged, I got comments from another > filesystem maintainer that were pretty much "great! we finally have > a filesystem maintainer who can stand up to Linus!". Is that in terms of being dicks, or in terms of technical ability? Or in terms of being super productive and focussed and able to get work done. Standing up doesn't mean you're right. Or wrong. > And having been on the receiving end of a lot of venting from them > about what was going on... And more that I won't get into... > I don't want to be in that position. So don't! Just step back a second. Go back and read and re-read all the comments Linus had made about the workflow and release process over the years, much less decades of the kernel development. I'm not sure you realize how much work it is to have people blasting patches at you all day long, 365 days a year, and who think their patches are the most important thing in the entire world bar none. Just reflect on this for a second. Take your hands off your keyboard, and don't type anything. And think about how many other people also think their patches are the most important. And about the users who _need_ _that_ _patch_ _right_ _now_ to fix a problem. Why doesn't Linus see that I'm important and my part of the kernel is the most important! Just let that sink in a bit. Then think about how many people do not care about bcachefs at all, who don't even know it exists. And haven't used it or want to use it. Are they less important? What about the graphics driver they need to get _their_ work done right now? Is that more or less important? > I'm just not going to have any sense of humour where user data integrity > is concerned or making sure users have the bugfixes they need. So release your own patches in your own tree! No one is stopping you! Have your '6.17-next' branch with the big re-working to fix this horrible issue. But send in just the minimal patch _now_. The absolutely the smallest patch. Or just send in a revert for all you have done in the current series which is breaking people, because it wasn't quite baked enough for stability. Fall back, re-group, re-submit it all on the next release. Slow down. > Like I said - all I've been wanting is for you to tone it down and stop > holding pull requests over my head as THE place to have that discussion. And you need to stop thinking you are the most important thing and only you can decide when bcachefs needs to be updated or not in the kernel tree. > You have genuinely good ideas, and you're bloody sharp. It is FUN > getting shit done with you when we're not battling. I'm honestly amazed at your abilities here Kent, even though you can be an abrassive person too. > But you have to understand the constraints people are under. Not > just myself. Dude, you need to listed to Linus saying this exact same line back to you. John
