Update the fwupd exception documentation to match the reality today

[superm1]

Description

Update the fwupd exception documentation to match the reality today

• Drop the handling for old releases that confused things
• Make it explicit that major versions aren't covered

---

Related issue

https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/2131001

Checklist

• I have read and followed the Ubuntu Project contributing guide
• My pull request is linked to an existing issue (if applicable)

[basak]

NAK. Upstream recommendations do not form SRU policy, and in this case contradicts SRU policy. Please do not emphasize this more. If anything, this should be removed because it implies that minimal patches to fix specific bugs are to be discouraged, contrary to Ubuntu SRU policy.

[superm1]

minimal patches to fix specific bugs are to be discouraged, contrary to Ubuntu SRU policy.

That's why this is an exception document. Upstream is not going to support Ubuntu if Ubuntu decides to go and patch things willy-nilly.

[basak]

Nobody said anything about patching things willy-nilly. Ubuntu SRU policy is supposed to ensure that cherry-picks are properly reviewed and QA'd.

[superm1]

Ubuntu SRU policy is supposed to ensure that cherry-picks are properly reviewed and QA'd.

This requires an in-depth understanding of the code and potential implications for a cherry pick with a non-obvious dependency.

[basak]

This requires an in-depth understanding of the code and potential implications for a cherry pick with a non-obvious dependency.

Absolutely. This is my expectation for any cherry-pick being made by a distribution.

[basak]

No backported individual patches.

That may be your preference, but it's not the position of the Ubuntu SRU team. Please remove this. I appreciate it was there before; I don't know how that slipped in.

[superm1]

It's an incredibly slippery slope to have backported patches when you have OEMs that specify requirements in their metadata on specific versions that go to LVFS.

Let me give you a hypothetical.

• There is plugin foo-bar for OEM Baz.
• Baz is testing with fwupd 2.0.0 in Ubuntu.
• They find a bug, and it's fatal. They work with upstream to fix the bug. Great.
• Upstream issues a 2.0.1 release.
• Ubuntu backports the patch that fixes fatal issue instead of updating to 2.0.1.

What does the OEM put in their metadata for requirements for the update? If they put 2.0.0 and someone is running the old version in Ubuntu (or 2.0.0 in say Fedora) they're going to cause the fatal problem. If they put 2.0.1 then it's safe everywhere but Ubuntu won't offer the update.

The only safe and scalable way is that they put 2.0.1, and that Ubuntu picks up 2.0.1. Anything else and there is risk to their users.

[basak]

My view is that your hypothetical situation illustrates precisely how upstream's version-check based architecture is flawed. Distributions have cherry-picked fixes as they feel appropriate pretty much forever. Debian in particular is by design supposed to deviate from upstream's preferences when Debian's own preferences (eg. Debian Policy, but also in other areas not specifically in Policy, such as privacy leak/phone home implications) require it. Upstream's choice in locking update downloads in to specific microrelease versions therefore plays poorly with existing practice in our ecosystem.

The right way to do this is for the metadata to state that some specific feature or bugfix (eg. with a bug reference) is required for a given update to work. Then the metadata should not say ">= 2.0.1" but "baseline 2.0 features with bugfix 123 and bugfix 125" for example. Even this should be applied sparingly when it is specifically necessary to prevent the sort of fatal issue you describe.

If upstream doesn't wish to fix their architecture, then we can work around it in distro. For example, we could add a mapping in a cherry-pick from ">= 2.0.1" to "baseline 2.0 features with bugfix 123 and bugfix 125" and then apply that check instead.

There are other ways to do this, but the principle remains that every distribution is entitled to cherry-pick as required as it feels appropriate to meet the needs of its individual users.

Of course doing this properly can require more effort and more maintenance, so we might well choose to take an upstream microrelease instead. SRU policy specifically permits this when all changes meet our quality requirements.

[superm1]

My view is that your hypothetical situation

It's been a while now - but we had this exact issue happen early on which is why this architecture was introduced and why the exception documentation was written this way.

Upstream's choice in locking update downloads in to specific microrelease versions therefore plays poorly with existing practice in our ecosystem.

It's actually an OEM's choice that mirrors their experience in failures from QA. An OEM won't introduce metadata to gate a version unless they've found a problem.

Of course doing this properly can require more effort and more maintenance, so we might well choose to take an upstream microrelease instead. SRU policy specifically permits this when all changes meet our quality requirements.

The only reason the microreleases exist is to support distros like Ubuntu which stay on older major releases.
If Ubuntu is going to stop taking microreleases it's a waste of effort upstream.

[basak]

If Ubuntu is going to stop taking microreleases it's a waste of effort upstream.

I made no suggestion that Ubuntu should stop taking microreleases. In fact I specifically pointed out that our policy explicitly permits them (with conditions). I'm merely refusing to implement a ban on cherry-picking or a recommendation contrary to normal Ubuntu packaging practice. Microrelease updates are still welcome, probably preferable, and can follow the documentation (or its update) as normal.

[basak]

That's why this is an exception document. Upstream is not going to support Ubuntu if Ubuntu decides to go and patch things willy-nilly.

This "special case documentation" is not going to be effective at stopping Ubuntu cherry-picking patches. I don't agree that we should do this. But even if this were what the project wanted, placing notes here isn't going to make that happen.

Any Ubuntu developer can submit an SRU at any time against any package. If it's a straightforward cherry-pick, it will be reviewed, accepted and released without reference to these docs. These docs are only used to establish consistency in process in specific cases to avoid subjective reviews flip-flopping.

The same applies to security updates. The Ubuntu Security Team has long held the position that cherry-picks of security fixes are preferable to taking whole upstream updates with a bunch of unrelated changes.

If you want to establish a process by which specific packages are banned by Ubuntu from receiving cherry-picks, and the project were to agree, then you'd need to insert something into the SRU process as well as change Ubuntu's security processes. This documentation isn't the place to introduce such a requirement on the sly. I certainly don't want the SRU team to be invoked ("you did what the SRU team's policy strongly recommends against!") were somebody to seek to do it. Therefore it is not appropriate to place this kind of assertion into the SRU special case documentation.

[basak]

My view is that your hypothetical situation illustrates precisely how upstream's version-check based architecture is flawed. Distributions have cherry-picked fixes as they feel appropriate pretty much forever. Debian in particular is by design supposed to deviate from upstream's preferences when Debian's own preferences (eg. Debian Policy, but also in other areas not specifically in Policy, such as privacy leak/phone home implications) require it. Upstream's choice in locking update downloads in to specific microrelease versions therefore plays poorly with existing practice in our ecosystem.

The right way to do this is for the metadata to state that some specific feature or bugfix (eg. with a bug reference) is required for a given update to work. Then the metadata should not say ">= 2.0.1" but "baseline 2.0 features with bugfix 123 and bugfix 125" for example. Even this should be applied sparingly when it is specifically necessary to prevent the sort of fatal issue you describe.

If upstream doesn't wish to fix their architecture, then we can work around it in distro. For example, we could add a mapping in a cherry-pick from ">= 2.0.1" to "baseline 2.0 features with bugfix 123 and bugfix 125" and then apply that check instead.

There are other ways to do this, but the principle remains that every distribution is entitled to cherry-pick as required as it feels appropriate to meet the needs of its individual users.

Of course doing this properly can require more effort and more maintenance, so we might well choose to take an upstream microrelease instead. SRU policy specifically permits this when all changes meet our quality requirements.

[basak]

Nobody said anything about patching things willy-nilly. Ubuntu SRU policy is supposed to ensure that cherry-picks are properly reviewed and QA'd.

[basak]

If Ubuntu is going to stop taking microreleases it's a waste of effort upstream.

I made no suggestion that Ubuntu should stop taking microreleases. In fact I specifically pointed out that our policy explicitly permits them (with conditions). I'm merely refusing to implement a ban on cherry-picking or a recommendation contrary to normal Ubuntu packaging practice. Microrelease updates are still welcome, probably preferable, and can follow the documentation (or its update) as normal.

[basak]

This requires an in-depth understanding of the code and potential implications for a cherry pick with a non-obvious dependency.

Absolutely. This is my expectation for any cherry-pick being made by a distribution.