** Description changed: This is to support Dell's new Atomic Docking. Plan to still use 1.5.x branch given the tight schedule. It's time we start to work on upgrading to 1.7.x and splitting its EFI source package. [Impact] - * Several components that are used in OEM projects need - to use the fwupd to support firmware update. + * Several components that are used in OEM projects need + to use the fwupd to support firmware update. - * This is be a SRU exception that follow protocol in - https://wiki.ubuntu.com/firmware-updates + * This is be a SRU exception that follow protocol in + https://wiki.ubuntu.com/firmware-updates [Test Plan] - * follow the steps in the SRU exception page. - Need to make sure it still works well even if secure - boot is on. + * follow the steps in the SRU exception page. + Need to make sure it still works well even if secure + boot is on. - * Given fwupd 1.7.4 is so new, I think we should extended - the date in proposed channel like 14 days. + * Given fwupd 1.7.4 is so new, I think we should extended + the date in proposed channel like 14 days. - * Plan to loop existing OEM project and also request for - more regression tests. + * Plan to loop existing OEM project and also request for + more regression tests. [Where problems could occur] - * Think about what the upload changes in the software. Imagine the change is - wrong or breaks something else: how would this show up? + * BIOS upgrade failed and brick the machine. + We test the fwupd in PPA and this does not happen. Given past + experience, this only happens as we use unstable/not-tested + bios from vendors. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. + * component fw upgrade and the component no longer working + Per OEM team experience, this only happens as we use + unstable/not-tested fw from vendors, or there are special + steps and we didn't follow up carefully enough. - * This must '''never''' be "None" or "Low", or entirely an argument as to why - your upload is low risk. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + * This must '''never''' be "None" or "Low", or entirely an argument as to why + your upload is low risk. + + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance
** Description changed: This is to support Dell's new Atomic Docking. Plan to still use 1.5.x branch given the tight schedule. It's time we start to work on upgrading to 1.7.x and splitting its EFI source package. [Impact] * Several components that are used in OEM projects need to use the fwupd to support firmware update. * This is be a SRU exception that follow protocol in https://wiki.ubuntu.com/firmware-updates [Test Plan] * follow the steps in the SRU exception page. Need to make sure it still works well even if secure boot is on. * Given fwupd 1.7.4 is so new, I think we should extended the date in proposed channel like 14 days. * Plan to loop existing OEM project and also request for more regression tests. [Where problems could occur] * BIOS upgrade failed and brick the machine. - We test the fwupd in PPA and this does not happen. Given past - experience, this only happens as we use unstable/not-tested - bios from vendors. + We test the fwupd in PPA and this does not happen. Given past + experience, this only happens as we use unstable/not-tested + bios from vendors. - * component fw upgrade and the component no longer working - Per OEM team experience, this only happens as we use - unstable/not-tested fw from vendors, or there are special - steps and we didn't follow up carefully enough. + * component fw upgrade and the component no longer working + Per OEM team experience, this only happens as we use + unstable/not-tested fw from vendors, or there are special + steps and we didn't follow up carefully enough. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. + * component fw upgraded and kernel driver/firmware in the ubuntu + the archive does not support it. + This is possible but has rarely happened before. And this is so + hard to know in advance if IHV didn't do their job well. - * This must '''never''' be "None" or "Low", or entirely an argument as to why - your upload is low risk. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + * Other possible failure: I think those are well-covered in the SRU + exception test plan. + fwupd not work as Secure boot is on. + dbus interface in-compatibility. + etc. [Other Info] - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + * Can't think of any so far. ** Description changed: This is to support Dell's new Atomic Docking. Plan to still use 1.5.x branch given the tight schedule. It's time we start to work on upgrading to 1.7.x and splitting its EFI source package. [Impact] * Several components that are used in OEM projects need to use the fwupd to support firmware update. * This is be a SRU exception that follow protocol in https://wiki.ubuntu.com/firmware-updates [Test Plan] * follow the steps in the SRU exception page. Need to make sure it still works well even if secure boot is on. * Given fwupd 1.7.4 is so new, I think we should extended the date in proposed channel like 14 days. * Plan to loop existing OEM project and also request for more regression tests. [Where problems could occur] * BIOS upgrade failed and brick the machine. We test the fwupd in PPA and this does not happen. Given past experience, this only happens as we use unstable/not-tested bios from vendors. * component fw upgrade and the component no longer working Per OEM team experience, this only happens as we use unstable/not-tested fw from vendors, or there are special steps and we didn't follow up carefully enough. * component fw upgraded and kernel driver/firmware in the ubuntu - the archive does not support it. - This is possible but has rarely happened before. And this is so - hard to know in advance if IHV didn't do their job well. + the archive does not support it. + This is possible but has rarely happened before. And this is so + hard to know in advance if IHV didn't do their job well. * Other possible failure: I think those are well-covered in the SRU - exception test plan. - fwupd not work as Secure boot is on. - dbus interface in-compatibility. - etc. + exception test plan. + fwupd not work as Secure boot is on. + dbus interface in-compatibility. + etc. [Other Info] - * Can't think of any so far. + * Two bugs will also be fixed with this SRU: lp:1954965, lp:1953573. ** Description changed: - This is to support Dell's new Atomic Docking. + This is to support Dell's new Atomic Docking and WD22TB4. Plan to still use 1.5.x branch given the tight schedule. It's time we start to work on upgrading to 1.7.x and splitting its EFI source package. [Impact] * Several components that are used in OEM projects need to use the fwupd to support firmware update. * This is be a SRU exception that follow protocol in https://wiki.ubuntu.com/firmware-updates [Test Plan] * follow the steps in the SRU exception page. Need to make sure it still works well even if secure boot is on. * Given fwupd 1.7.4 is so new, I think we should extended the date in proposed channel like 14 days. * Plan to loop existing OEM project and also request for more regression tests. [Where problems could occur] * BIOS upgrade failed and brick the machine. We test the fwupd in PPA and this does not happen. Given past experience, this only happens as we use unstable/not-tested bios from vendors. * component fw upgrade and the component no longer working Per OEM team experience, this only happens as we use unstable/not-tested fw from vendors, or there are special steps and we didn't follow up carefully enough. * component fw upgraded and kernel driver/firmware in the ubuntu the archive does not support it. This is possible but has rarely happened before. And this is so hard to know in advance if IHV didn't do their job well. * Other possible failure: I think those are well-covered in the SRU exception test plan. fwupd not work as Secure boot is on. dbus interface in-compatibility. etc. [Other Info] * Two bugs will also be fixed with this SRU: lp:1954965, lp:1953573. ** Description changed: - This is to support Dell's new Atomic Docking and WD22TB4. + This is to support Dell's new Atomic Docking and WD22TB4 in focal. - Plan to still use 1.5.x branch given the tight schedule. - - It's time we start to work on upgrading to 1.7.x and splitting its EFI - source package. + As fwupd 1.7.x efi splie is done, let use 1.7.4 for this. [Impact] * Several components that are used in OEM projects need to use the fwupd to support firmware update. * This is be a SRU exception that follow protocol in https://wiki.ubuntu.com/firmware-updates [Test Plan] * follow the steps in the SRU exception page. Need to make sure it still works well even if secure boot is on. * Given fwupd 1.7.4 is so new, I think we should extended the date in proposed channel like 14 days. * Plan to loop existing OEM project and also request for more regression tests. [Where problems could occur] * BIOS upgrade failed and brick the machine. We test the fwupd in PPA and this does not happen. Given past experience, this only happens as we use unstable/not-tested bios from vendors. * component fw upgrade and the component no longer working Per OEM team experience, this only happens as we use unstable/not-tested fw from vendors, or there are special steps and we didn't follow up carefully enough. * component fw upgraded and kernel driver/firmware in the ubuntu the archive does not support it. This is possible but has rarely happened before. And this is so hard to know in advance if IHV didn't do their job well. * Other possible failure: I think those are well-covered in the SRU exception test plan. fwupd not work as Secure boot is on. dbus interface in-compatibility. etc. [Other Info] * Two bugs will also be fixed with this SRU: lp:1954965, lp:1953573. ** Description changed: This is to support Dell's new Atomic Docking and WD22TB4 in focal. As fwupd 1.7.x efi splie is done, let use 1.7.4 for this. [Impact] * Several components that are used in OEM projects need to use the fwupd to support firmware update. - * This is be a SRU exception that follow protocol in + * This will follow the SRU exception in https://wiki.ubuntu.com/firmware-updates [Test Plan] * follow the steps in the SRU exception page. Need to make sure it still works well even if secure boot is on. * Given fwupd 1.7.4 is so new, I think we should extended the date in proposed channel like 14 days. * Plan to loop existing OEM project and also request for more regression tests. [Where problems could occur] * BIOS upgrade failed and brick the machine. We test the fwupd in PPA and this does not happen. Given past experience, this only happens as we use unstable/not-tested bios from vendors. * component fw upgrade and the component no longer working Per OEM team experience, this only happens as we use unstable/not-tested fw from vendors, or there are special steps and we didn't follow up carefully enough. * component fw upgraded and kernel driver/firmware in the ubuntu the archive does not support it. This is possible but has rarely happened before. And this is so hard to know in advance if IHV didn't do their job well. * Other possible failure: I think those are well-covered in the SRU exception test plan. fwupd not work as Secure boot is on. dbus interface in-compatibility. etc. [Other Info] * Two bugs will also be fixed with this SRU: lp:1954965, lp:1953573. ** Description changed: This is to support Dell's new Atomic Docking and WD22TB4 in focal. As fwupd 1.7.x efi splie is done, let use 1.7.4 for this. [Impact] * Several components that are used in OEM projects need to use the fwupd to support firmware update. * This will follow the SRU exception in https://wiki.ubuntu.com/firmware-updates [Test Plan] * follow the steps in the SRU exception page. Need to make sure it still works well even if secure boot is on. * Given fwupd 1.7.4 is so new, I think we should extended the date in proposed channel like 14 days. * Plan to loop existing OEM project and also request for more regression tests. [Where problems could occur] - * BIOS upgrade failed and brick the machine. + * BIOS upgrade failed and brick the machine: We test the fwupd in PPA and this does not happen. Given past experience, this only happens as we use unstable/not-tested bios from vendors. - * component fw upgrade and the component no longer working + * component fw upgrade and the component no longer working: Per OEM team experience, this only happens as we use unstable/not-tested fw from vendors, or there are special steps and we didn't follow up carefully enough. * component fw upgraded and kernel driver/firmware in the ubuntu - the archive does not support it. + the archive does not support it: This is possible but has rarely happened before. And this is so hard to know in advance if IHV didn't do their job well. + This only happened in case that the failed fw is not supported + in the previous fwupd, but it supported in the new fwupd, and + the new fw happened not been supported by existing + kernel driver/linux-firmware deb. + We will notify OEM projects to be aware of it, so it won't + break things. - * Other possible failure: I think those are well-covered in the SRU + * Other possible failures: those are well-covered in the SRU exception test plan. - fwupd not work as Secure boot is on. - dbus interface in-compatibility. - etc. + - fwupd does not work as Secure boot is on. + - dbus interface in-compatibility. [Other Info] * Two bugs will also be fixed with this SRU: lp:1954965, lp:1953573. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1949412 Title: Upgrade fwupd for Atomic Docking Support To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1949412/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
