Hi Robbie,
On 4/14/22 20:02, Robbie Harwood wrote:
Hans de Goede <hdegoede(a)redhat.com> writes:
> 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.
As I've mentioned multiple times elsewhere, this isn't about packages,
and I don't think it's helpful to think in terms of them.
> 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:
Trying to avoid re-hashing our lengthy off-list conversation, here are
some thoughts (mine and other interested parties's):
At minimum, we need a Legacy BIOS SIG to provide:
- a "place" to assign bugs (e.g., email address)
- a means to fix issues
By default, we understand the former to be the SIG's email address, and
the latter to be PRs to dist-git of relevant packages.
The overall goal of the SIG needs to be to reduce load on existing
bootloader contributors.
Ack I agree that bugzilla triage of BIOS boot bugs +
fixing them once identified needs to be the main focus
of the SIG.
That and regularly testing N + 1 boot media BIOS booting
to catch any regressions early on.
If it is not doing this, it needs to be
dissolved.
## SIG package maintenance
If the SIG wants to maintain any BIOS-only packages, that's up to them.
Assuming Brian's change to use grub2 instead of syslinux on legacy
install media (
https://github.com/weldr/lorax/pull/1226 ), the only
other packages in question here would be those to support VESA/fbdev:
- xorg-x11-drv-vesa
- xorg-x11-drv-fbdev
- xorg-x11-server-Xorg
I personally do not believe that it will be necessary to keep
maintaining VESA support, I agree that without legacy BIOS
support it definitely is not needed though. I believe that ajax
has submitted a separate change proposal for this, so this is
best discussed there.
- syslinux
As you say it looks like this one may no longer be necessary and
otherwise the SIG can pick it up.
## Fedora deliverables
Given there is consensus that legacy BIOS is on its way out, we think
Fedora release criteria in this area should be re-evaluated. Not only
does support change from "fully supported" to "best effort", but we
should re-evaluate what is/isn't release blocking, and probably clarify
who owns what parts.
Given what the server product folks have indicated that BIOS
boot support is quite important for them I'm not sure if changing the
release criteria is in order. I do agree that any blocker bugs related
to legacy BIOS booting should be assigned to; and taken care of by
the legacy BIOS boot SIG.
## grub2
By default, the Legacy SIG is expected to perform contributions in the
form of triage and PRs. Normal “upstream first” rules apply here (i.e.,
send it wherever possible, otherwise send to the downstream rhboot
repo).
Current grub2 maintainers consider splitting the package (probably grub2
and grub2-pc, to match current naming, or grub2-legacy or something)
undesirable for a number of reasons. A nonexhaustive list of what would
need to be satisfactorily resolved before a split could considered:
- There needs to be a primary (and probably secondary) package owner
from the SIG as a prerequisite for a new bugzilla component.
- Everything in grub2-common, grub2-tools, and grub2-tools-extra is
available on both UEFI and legacy. In most cases, the content is in
fact shared: one file works on both.
- The new grub2-bios is secondary to the main grub2 package, which means
that the Legacy SIG is responsible for not conflicting with any grub2
subpackage, and nothing in grub2 can depend on anything in the legacy
package.
- More generally, problems with the shared core can and will manifest
primarily on one platform. Bugzilla ping-pong needs to not be played.
- Feature incompatibilities can and will occur. (Maybe this is okay, or
just the Legacy SIG's responsibility to sort out in all cases.)
- Current maintainers do not have much capacity for mentoring, and since
the point is to be rid of legacy, we can't help much at all with
bugfixes.
Ok, if you prefer going through PR-s then lets give that a try,
I'm a bit worried that always needing to go through the bootloader team
may get in the way of expedient fixing of BIOS related bugs and that
this may cause extra work for the bootloader team at inconvenient times.
But lets see how this goes, we can always reconsider this later.
Regards,
Hans