Hi Robbie, On 4/14/22 20:02, Robbie Harwood wrote: > Hans de Goede <hdego...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
