I feel for the stable series maintainer

Posted Dec 11, 2023 2:31 UTC (Mon) by welinder (guest, #4699)
Parent article: Ext4 data corruption in stable kernels

He is damned if he does and he is damned if he doesn't. And he is probably also damned if he dithers.

The job basically is to apply patches new kernels to a baseline that has diverged. You can hope that the meaning of the patch is the same over the old baseline, but without super-human understanding of both patch and old baseline there is not much you can do but taking the word of the subsystem maintainer.

And then something like this comes along where the effect of the patch probably was the same in the mainline and the stable series, just not the effect that was intended. And blame is sent in the general direction of the stable series maintainer.

Well, if we ever meet I owe you a drink.

I feel for the stable series maintainer

Posted Dec 11, 2023 7:30 UTC (Mon) by epa (subscriber, #39769) [Link]

Surely part of the problem is that only a small proportion of development work happens on the stable branch.

If there are new features in development it makes sense to add those to an unstable branch (which could even be the master branch). But if you’ve found a bug which affects a stable release, maybe the fix should be applied to that stable branch first, then forward-ported to unstable if needed. (If there are multiple stable branches then the oldest and “most stable” is probably the place to start for critical fixes.)

This would not have stopped the commit causing the problem getting into stable, but it might have made sure the second commit (without which the first is buggy) also got in.

The model of hacking on the latest version first, then deciding what to backport, seems more appropriate for new features—where a stable maintainer might decide to include a new driver, for example.