Robie,
My apologies; my email didn't get a response a while and I was on leave
a while when your response came back and I totally missed it.
Your comment on bug 1979963 prompted me to find it though!
On 3/7/24 08:00, Robie Basak wrote:
Hi Mario,
Thank you for caring for the fwupd package in Ubuntu!
Sure.
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?
I am part of ~ubuntu-foundations-team, but admittedly I have not
conferred closely with other members.
I would invite discussion on any opposing views from other members.
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 think there's a big difference between "not touching" and "supporting".
Due to the LVFS server changes that I've alluded to and Richard
mentioned fwupd from 18.04 LTS and 16.04 are essentially dead software
right now.
In a sense due to the upstream EOL dates the difficulty of "maintaining"
very old versions becomes exponentially greater as the software progresses.
It's not my day job to maintain fwupd but it's something I like to work
on upstream, and I do my best to keep it healthy where and when I can in
Ubuntu.
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.
I understand the position; but I have been privy to patches that are
backported "look" like they're complete but actually introducing a bug
because they're missing non-obvious patches already on the stable branch.
This is a strong reason that we keep the CI infrastructure that relies
upon device emulation working even on the stable upstream branches to
catch even our cases of missing dependencies in cherry picks. We're
constantly improving this upstream and will be instituting a policy in
the future that new (USB) plugins can't go in without emulation data for
a real device.
Is there a happy medium? Aim for updated tarballs but maybe a
discussion with upstream before bringing SRU patches in?
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.
Richard mentioned the server changes that happened and even the
extension of how RHEL is updating in their minor releases.
I don't feel that hardware enablement in LTS releases is happening
appropriately. The SRU that I staged enables updates for devices that
OEMs ship or certify with Ubuntu that they couldn't update them.
If an OEM is making such a big investment to try to make Ubuntu a good
experience there should be a way to support them by pulling in the newer
hardware support as well.
In summary; it already happens for things like the kernel and mesa,
fwupd should be part of the scope too.
Thanks,
Robie
[1] https://wiki.ubuntu.com/StableReleaseUpdates#When
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
