On 11/07/2014 04:24 PM, Peter Jones wrote:
On Fri, Nov 07, 2014 at 11:34:16AM -0800, Adam Williamson wrote:
More criteria time, folks!
So we managed to get the Windows multi-boot criterion revised and an OS
X multi-boot criterion added, but we did not yet manage to come to a
consensus on exactly what should be required for Linux multi-boot.
I think Chris will re-propose his last idea and we can discuss it a bit
more, but I'd like to suggest a more restricted criterion we can
hopefully agree on immediately for the short term:
===
When installing to a system containing an existing installation of
either the same Fedora release or either of the two previous releases,
the installer must configure the new installation's bootloader such that
it can successfully boot the existing installation.
[Footnote] Typical configurations only: This criterion applies only to
installations (both existing and new) using default or very common
storage and bootloader configurations.
[Footnote] Platforms: This criterion applies to all supported
configurations described in
[[Fedora_21_Alpha_Release_Criteria#Release-blocking_images_must_boot|the
Alpha criteria]], but does not apply to mixed configurations, e.g. it
does not require that a UEFI native installation of one Fedora release
be able to configure its bootloader to boot a BIOS native installation
of another Fedora release.
===
How does that look? I think we had at least a consensus that this much
was reasonable, and we have two bugs currently that would likely violate
the proposed criterion:
https://bugzilla.redhat.com/show_bug.cgi?id=825236
https://bugzilla.redhat.com/show_bug.cgi?id=964828
I think it's reasonable to consider these blockers for F21, but we
should justify it ASAP to give the devs sufficient time to fix them.
I'm all for getting those bugs fixed, but making it an official
criterion is basically adding an anaconda requirement and a new feature
to the distro. Doing that at the end of a cycle isn't really okay, and
doing it without any mention on anaconda-devel-list or fedora-devel-list
for discussion isn't really that great, either.
Also this criterion as written is going to bring in more than just those
two bugs - for example, right now we don't /really/ support two UEFI
Fedora installations on a single disk without the user making some
fairly strange choices, and when you do that, some things such as
fallback (which admittedly aren't in the criteria AFAIK) don't work.
Fixing that would be a fairly substantial RFE, so either we need to have
language in any potential new criterion to accept the current conditions
(e.g. by requiring two separate disks to put an ESP on each), or we need
to plan on adding support for that before we apply any new criteria.
Before discussion any criteria for whatever release, perhaps there
should be a discussion on how we would like things to work and what we
really do not care about. Also, I believe that the appropriate place
for this discussion is the anaconda-devel list and/or
de...@lists.fedoraproject.org [or, perhaps both].
Also, is this just a grub2 issue or does it also apply to extlinux?
Also, I would like to see the merits of directly booting other
installations (linux/initrd) versus configfile chaining.
Another point that would clarify things for me concerns
linux16/initrd16. Other than it is the "latest and greatest, just what
features/capabilities does linux/initrd (32 bit) offer that is not
available in linux16/initrd16?
Once we know what goal we are aimed at and what we are ignoring, then we
can establish some bounds and release criteria. And yes, it is far too
late for Fedora 21 and will be too late for Fedora 22 if the discussion
and decisions are not done soon. As Peter points out, some RFE things
will involve a substantial amount of code and therefore need lots of
lead time.
Gene
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
