←back to thread

Bcachefs may be headed out of the kernel

(lwn.net)
144 points ksec | 2 comments | 04 Jul 25 13:32 UTC | HN request time: 0.431s | source
Show context
criticalfault ◴[04 Jul 25 17:57 UTC] No.44466573[source]▶
I've been following this for a while now.

Kent is in the wrong. Having a lead position in development I would kick Kent of the team.

One thing is to challenge things. What Kent is doing is something completely different. It is obvious he introduced a feature, not only a Bugfix.

If the rules are set in a way that rc1+ gets only Bugfixes, then this is absolutely clear what happens with the feature. Tolerating this once or twice is ok, but Kent is doing this all the time, testing Linus.

Linus is absolutely in the right to kick this out and it's Kent's fault if he does so.

replies(8): >>44466668 #>>44467387 #>>44467968 #>>44468790 #>>44468966 #>>44469158 #>>44470642 #>>44470736 #
bgwalter ◴[04 Jul 25 21:20 UTC] No.44467968[source]▶
bcachefs is experimental and Kent writes in the LWN comments that nothing would get done if he didn't develop it this way. Filesystems are a massive undertaking and you can have all the rules you want. It doesn't help if nothing gets developed.

It would be interesting how strict the rules are in the Linux kernel for other people. Other projects have nepotistic structures where some developers can do what they want but others cannot.

Anyway, if Linus had developed the kernel with this kind of strictness from the beginning, maybe it wouldn't have taken off. I don't see why experimental features should follow the rules for stable features.

replies(3): >>44468097 #>>44471052 #>>44471394 #
yjftsjthsd-h ◴[04 Jul 25 21:44 UTC] No.44468097[source]▶
If it's an experimental feature, then why not let changes go into the next version?
replies(1): >>44468133 #
bgwalter ◴[04 Jul 25 21:53 UTC] No.44468133[source]▶
That is a valid objection, but I still think that for some huge and difficult features the month long pauses imposed by release cycles are absolutely detrimental.

Ideally they'd be developed outside the kernel until they are perfect, but Kent addresses this in his LWN comment: There is no funding/time to make that ideal scenario possible.

replies(3): >>44468166 #>>44468709 #>>44473730 #
1. motorest ◴[05 Jul 25 16:17 UTC] No.44473730[source]▶
> That is a valid objection, but I still think that for some huge and difficult features the month long pauses imposed by release cycles are absolutely detrimental.

I feel you're not answering the question, nor are you presenting any case in favor of forcing an exceptional release process for an unstable feature.

The "detrimental" claim is also void of any reason or substance. It's not to it's users as users know better than rolling out experimental file systems for critical data, and those hypothetical users who somehow are really really interested in using bleeding edge will already be building their own kernel for this reason alone. Both scenarios don't require this code to be in the kernel, let alone exceptional release processes.

> Ideally they'd be developed outside the kernel until they are perfect, but Kent addresses this in his LWN comment: There is no funding/time to make that ideal scenario possible.

It is clear then that the code should be pulled from the kernel. If it isn't impossible to maintain a feature with the regular release process, everyone stands to benefit by not shipping code that is impossible to stabilize.

replies(1): >>44474525 #
2. bgwalter ◴[05 Jul 25 18:20 UTC] No.44474525[source]▶
> The "detrimental" claim is also void of any reason or substance.

Thanks for the compliments! Detrimental for development speed, not for the users.