> > === > > > > 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. I'm in favor of adding such a criterion. And I agree it's too late for F21, so it should target F22. Of course, that doesn't preclude anaconda devs from best-effort to fix those bugs, if they have spare time. > > 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. I was about to mention the same, Fedora UEFI dual-boot requires a lot of manual tweaking at the moment, and I guess it's not something that can be changed and properly tested in a few weeks. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
