Refine the firmware-updates exception

[Robie Basak]

Hi Mario,

Thank you for caring for the fwupd package in Ubuntu!

One adminsitrative question: fwupd is in main and the Foundations team
are committed to looking after it. Is your proposal made on behalf of or
in coordination with the Foundations team? If not, what's the Foundation
team's view on your proposal?

On Sun, Feb 18, 2024 at 12:11:48AM -0600, Mario Limonciello wrote:
> Considering all of that, I wanted to discuss with the release team to
> modify the exception used for the firmware updating stack to allow
> migrations from one stable branch to another; especially considering EOL
> dates.
> I've drafted an updated proposal in this wiki page and aligned it
> directionally upstream:
> https://wiki.ubuntu.com/firmware-updates-2.0
> 
> Can the release team please review and consider this?  If approved we can
> just copy the text from the new page to the old page and delete the new
> page.

In general we only grant general permission to make arbitrary feature
changes to packages in stable releases under specific circumstances[1].
Probably the relevant reasons in the case of this package would be for
hardware enablement purposes, or in the case of "Internet protocol"
changes (eg. for fwupd, perhaps the mechanism to fetch updates is
changing and will no longer work).

Notably, upstream advertising "EOL dates" is *not* a valid
justification. Consider this: Ubuntu already commits to supporting an
LTS release for 10 years. How many upstreams that "publish EOL dates"
would still be supporting their releases that we shipped by the end of
that period? I'd guess virtually zero. Clearly, we are committing to
"LTS-ness" for our entire stable release cycle *despite* "upstream EOL
dates" - in effect *extending* those dates for our users. Or, consider
what would happen if "upstream EOL dates" *were* justification for us to
make major version bumps to our packages. Near the end of our stable
release cycle, this would mean that we'd effectively become a rolling
release as every package for which upstream had published an "EOL date"
would need to be updated. Clearly this is not the intention, so clearly
"upstream EOL" cannot be a justification in itself for us to bump a
major version in a stable release.

> I've drafted an updated proposal in this wiki page and aligned it
> directionally upstream:
> https://wiki.ubuntu.com/firmware-updates-2.0

One further note from your draft:

> tarball releases only. No backported individual patches.

I understand the benefit of aligning with upstream. However this is only
possible if upstream policies completely align with distribution policy
and expectations. There is no guarantee of this in the future, so from a
policy point of view, distribution-specific patches must never be ruled
out by a general policy like this. Instead, I expect uploaders and the
SRU team to continue considering such patches on a case-by-case basis.
It is normal and a common occurrence for the SRU team to push back on a
large set of updates and ask for a minimal cherry-pick to minimise risk
to users, and I don't see any reason that the fwupd should diverge from
this position. Therefore, IMHO this stipulation cannot form part for a
policy that the SRU team can accept.


Given the above points, I'm unclear what basis remains for the change
that you're requesting. Why can fwupd not continue being maintained in
the distribution like any other package? If there are specific
challenges with respect to hardware enablement or Internet protocol
changes for example, I'd be grateful if you could spell these out
please.

Thanks,

Robie


[1] https://wiki.ubuntu.com/StableReleaseUpdates#When
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20240307/75fca0b1/attachment.sig>