Removing Optical Boot Requirement from F20 Alpha Release Requirements

Tim Flink tflink at redhat.com
Thu Sep 19 10:54:01 UTC 2013


On Thu, 19 Sep 2013 06:23:04 -0400
Bob Lightfoot <boblfoot at gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/19/2013 05:26 AM, Kamil Paral wrote:
> >> This conversation was started on Monday in the QA meeting but I
> >> forgot to send anything out to the list. We're a bit short on
> >> time, so a quick vote would be appreciated
> >> 
> >> Tim
> >> 
> >> 
> >> As currently written, the Fedora 20 alpha release requirements
> >> [1] state that optical media must boot:
> >> 
> >> Release-blocking live and dedicated installer images must boot
> >> when written to optical media of an appropriate size (if
> >> applicable) and when written to a USB stick with at least one of
> >> the officially supported methods.
> >> 
> >> [1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-blocking_images_must_boot
> >>
> >>
> >>
> >> 
> The question was whether it was important to have this requirement at
> >> alpha when the isos aren't required to be the correct size until
> >> beta. As it currently stands, the DVD isos can't be burned to
> >> single-sided DVDs.
> >> 
> >> I propose that we modify that we do two things:
> >> 
> >> 1) modify the alpha criterion so that it only requires optical
> >> media to work if the isos are correctly sized
> >> 
> >> 2) require booting from optical media at beta when the isos are 
> >> required to be properly sized
> >> 
> >> Proposed change to the "supported media types" section of the
> >> release blocking media criterion [1] :
> >> 
> >> Release-blocking live and dedicated installer images must boot
> >> when written to optical media of an appropriate size (if
> >> applicable and the images are correctly sized) and when written
> >> to a USB stick with at least one of the officially supported
> >> methods. Release-blocking ARM disk images must boot when written
> >> to a medium bootable by the platform under test, according to the
> >> instructions for the platform under test.
> >> 
> >> [1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-blocking_images_must_boot
> >>
> >>
> >>
> >> 
> Proposed change to the beta release blocking image criterion [2]:
> >> 
> >> Difference from Alpha: This criterion differs from the similar
> >> Alpha criterion in that it requires optical media to boot and
> >> that all supported methods of writing a Fedora USB stick to work,
> >> not just any single one.
> >> 
> >> [2]http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Release-blocking_images_must_boot
> >
> >> 
> > I agree.
> > 
> > However, there's one corner case to consider. Due to some licensing
> > issues we still can't test UEFI in VMs. That means we can't really
> > test UEFI boot and installation of Live/DVD/netinst other than
> > burning it (or doing a USB conversion, but then we don't test the
> > vanilla ISO). If Live/netinst burning is broken for some reason
> > (other than being oversize, which is not very likely for these two
> > images), we might have troubles verifying that UEFI works. OTOH
> > this is a very unlikely situation to occur. I'm mentioning it for
> > completeness.
> > 
> The rewrite sounds good to me.  Just one possible improvement.  I work
> almost exclusively with VM for testing so iso size doesn't matter.
> Should it be an alpha requirement that the isos we're talking about
> boot and install in the VM environment which has no care for size?
> Does this gain us any sanity checking?

That's an good point. In practice, we seem to be doing a lot if not
most of the testing for alpha in VMs and it might be worth looking into
moving the "must work in a VM" criterion to alpha for f21.

I'd rather not mess with the criteria any more than we have to this far
into alpha, though. VMs are working at the moment and I think we can
get away with not formalizing the desire for them to work at alpha for
f20.

Tim


> Bob
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJSOtCHAAoJEKqgpLIhfz3XFRMH/30aiKVVMOMtQHPujSUNvzaZ
> L+ukAflPlXguMe0jFIUNt9J6fBIkKpTA2QZeupO0yFQF42kaFCALAGdmZYvK4Iiv
> iGmY0UffTJqlxYVOsJtFtJ1iUEuRwvPlyByLMyycX9F+rlXYnuSooZpqz6Fi2Zuf
> CLCB83rcLPxOgH1cYKxYWg8mcISvG01HXjwn5DZJcr5rto48SFLeiVdmPtn/SNtQ
> fHfLW51i3qENli48lXjIPhj0trTw1u3pfQK0+UCijSB/kFU3EFi/yul3U9WbfqNG
> 3ul+FbtTKwxk80eRJtHiepPCdIrF1XCBW80iw+4RWiPTCCMEWkNpY1SVFh2c4tE=
> =L/mM
> -----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20130919/bfb8dc24/attachment.sig>


More information about the test mailing list