Ping? ________________________________ From: Mario Limonciello <supe...@gmail.com> Sent: Wednesday, May 1, 2024 10:32:49 AM To: Robie Basak <robie.ba...@ubuntu.com>; Mario Limonciello <supe...@ubuntu.com> Cc: ubuntu-release@lists.ubuntu.com <ubuntu-release@lists.ubuntu.com>; Richard Hughes <hughsi...@gmail.com> Subject: Re: Refine the firmware-updates exception
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
