Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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).
"""

Regards,

Hans

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux