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]

 



Hans de Goede <hdegoede@xxxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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