Comment 28 for bug 1874831

I think Christian's feeling is right.

SRU policy is to cherry-pick specific fixes. Normally we'd expect a bug report to have identified a root cause in the code, and we'd be patching that root cause to fix the problem.

Identifying that one version works and one version does not, and therefore we should swap the version in a stable release, doesn't comply with this requirement and isn't normally acceptable because there usually exist users not affected by the bug who might find that behaviour for them changes, contrary to their expectations of a stable release. It's also incomplete to just identify version differences like this: there is always going to be a root cause in the code, so it should always be possible to turn this case into the first case above and therefore to find a way to update the package with which we can be more confident doesn't disrupt existing unaffected users.

Exceptionally, if we can be certain that there aren't any existing unaffected users, then we can bump the version safely. Or if it's not practical to do the above step, we might decide that the "least worst" solution is to take that risk. But then I'd expect the case to be made that there are no existing unaffected users and therefore there can be no disruption by the version bump. Or an explanation of why it is not practical to turn this into the first case and risking regression to existing users is "least worst".

Christian said:

> But as we've seen it seems there are (basic?) configurations which were fine before, therefore I'm not entirely sure we can really push this as an SRU :-/

That does sound to me like a cherry-pick is required here, unless a case is made for the exceptions I outlined above.