That does seem to be one of the big disconnects, yes.

In the past I've argued that I do need a relatively free hand and to be able to move quickly, and explained my reasoning: we've been at the stage of stabilization where the userbase is fairly big, and when someone reports a bug we really need to work with them and fix it in a timely manner in order to keep them testing and reporting bugs. When someone learns the system well enough to report a bug, that's an investment of time and effort on their part, and we don't want to lose that by having them get frustrated and leave.

IOW: we need to prioritize working with the user community, not just the developer community.

All that's been ignored though, and the other kernel maintainers seem to just want to ratchet down harder and harder and harder on strictness.

At this point, we're past the bulk of stabilization, and I've seen (to my surprise) that I've actually been stricter with what I consider a critical fix than other subsystems.

So this isn't even about needing special rules for experimental; this is just about having sane and consistent rules, at all.

I have seen your work and have some experience in kernel development. I think the situation is bad for everyone involved: you and linux. I would suggest trying to restart the conversation only focused on experimental feature changes.

In specific, I think there should be am effort to have a label (doesn't matter what one, hidden behind something like "icantbelieveitsnotbcachefs") where then you're (and not just you but anyone who wants to contribute changes to experimental features) allowed to push changes all the time.

That was already working for btrfs and will probably work for btrfs too.

Your argument about reducing feedback time can be a good argument in general. Yo shouldn't approach this as "im right allow me to push code, but start a different conversation about quick testing of experimental code with minimal friction. And make a case in general for linux to have this system.