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. 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 - syslinux ## 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. ## 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. Be well, --Robbie
signature.asc
Description: PGP signature
_______________________________________________ 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
