On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: > Hi, > > On 4/13/22 18:07, David Cantrell wrote: > > On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote: > >> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell > >> <dcantrell@xxxxxxxxxx> wrote: > >>> The core issue still comes down to having resources to continue > >>> maintaining > >>> BIOS boot support in Fedora and so far no one has come forward to work > >>> on > >>> that. > >> > >> It's not true, although you can be forgiven for missing it in such a massive > >> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a > >> very credible proposal. > > > > Ah, yes. I do remember the post from Hans, but thought he was more outlining > > how a Legacy BIOS SIG could work and what would need to happen rather than > > volunteering to set one up and do that. But I went back and reread that post > > and yes, he did volunteer to do just that. > > Correct. > > > If a video call happens to discuss this feature proposal, ensure Hans can > > attend. > > FWIW, ATM I think everything which can be said about > this has been said and I'm not sure if having a video > call about this will add anything new. Agreed. > As for setting up the SIG if necessary, my plan is to > try to keep the SIG lite weight on the process side > and focus on the practical things. > > What I envision for the SIG is: > > 1. I'm not sure if it is possible to setup group ownership > of pkgs in pagure? So to keep things simple the few packages which > are only necessary for BIOS boot can be handed over to me and then > I'll just add other people willing to help out as co-maintainers. > > 2. Setup a mailinglist for this and have that in bugzilla + PR > Cc for all the relevant packages. > > 3. Have people from the SIG regularly test Fedora N and > Fedora N + 1 (after branching) on machines which only support > BIOS booting and file bugs (if any) + report the results to > the mailinglist. > > 4. Have people from the SIG try to regularly do bugzilla > triage of relevant packages. > > And I would also like to have a discussion about splitting > the BIOS boot grub bits out into a separate src.rpm > (using the same Source0 as the main grub) so that this can > be build by the SIG without needing help from the bootloader > team (the main grub package can only be built by a few people > because of secureboot signing). The idea is to avoiding > bottlenecking on the bootloader team when some BIOS boot bugs > in grub need to be fixed, quoting from my original email about > this: > > """ > I've been thinking about how this could be done for grub; also > because of the issue that the EFI builds of grub need to be > signed with Fedora's secure boot keys, which means only a few > people can do grub2 builds atm. > > One option which I think we should consider is sticking with > a single downstream git fork (until we have managed to get > everything we need upstream), so stick with: > > https://github.com/rhboot/grub2/ > > As the Source0 provider for the packages and then next to: > > https://src.fedoraproject.org/rpms/grub2 > > Add a: > > https://src.fedoraproject.org/rpms/grub2-bios > > And moving the build of all sub-packages which are > only necessary for BIOS support to the second src.rpm. > > This way the Legacy BIOS SIG could maintain > the grub2-bios src.rpm (and binary pkgs it builds). > The SIG _must_ then of course still submit pull-reqs to: > https://github.com/rhboot/grub2/ for any changes. > > But in case of e.g. a beta blocking BIOS only bug they > could solve that with a patch in the src.rpm and kickof > a build right away without blocking on the bootloader > team and thus without causing a spike in > work-pressure/load for the bootloader team. > > And then once the pull-req is merged (possibly > a revised version of it) the next build of > the grub2-bios src.rpm can pull in the new Source0 > and drop its local changes (IOW grub2-bios _must_ > not become a separate fork). > """ OK, given this proposal, I'd like the original change proposal amended to essentially say "transfer legacy BIOS boot support to newly formed Legacy BIOS SIG" or something like that. The logistics at that point can be sorted out as the SIG sees fit. I'd like to see the original proposal advance forward and this gives a plan for the legacy BIOS piece. Can you followup with the proposal owners to make that amendment? Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
