On Tue, 26 Jan 2016 18:19:41 +0100, Paul W. Frields <stickster@xxxxxxxxx>
wrote:
On Mon, Jan 25, 2016 at 11:28:25PM -0800, Adam Williamson wrote:
On Mon, 2016-01-25 at 11:59 -0500, Paul W. Frields wrote:
>
> IIRC we aren't blocking on LUC currently -- so whether this means
> reviving old criteria or creating new ones, that needs to be clear.
Actually we are, though we have been known to handwave it a little:
Thanks for the correction.
"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 any of the officially supported
methods."
from https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria ,
it's the first footnote to "Release-blocking images must boot", titled
"Supported media types". So the official rule is that we block on all
three 'officially supported methods' - dd-style write, litd, and luc.
There's a bunch of wiggle room in terms of exactly how well we expect
luc to work, and what exactly it means to 'block a release' on
something that is not part of the release, but the criterion is there.
In a recent release (maybe a year ago?) I recall we discussed whether
we needed to pull out some stops to fix a LUC issue. I think my
confusion about blocking may have come from that (sorry, it's hazy and
I've no time to play email archaeology at the moment). :-)
But as you mention below, I agree we should cut down on the different
vectors here, and do a better job of supporting one.
> OTOH, the functions of LUC are pretty well constrained. So maybe this
> isn't too large a change.
What would actually be an *improvement* is if we killed litd and luc's
'cp mode', and only supported the new dd-only luc and dd-style writes.
That would substantially reduce the exposure we currently have to three
different writing modes: dd, litd, and luc-cp.
Agreed -- I think I heard (maybe elsewhere in this thread?) that the
plan was to remove the cp option in LUC, but I'll check with mbriza.
To avoid the communication ping pong on IRC:
Yes, I'm removing the cp support from the code now in the feature/onlydd
branch [1]. While I don't say the feature won't be reintroduced in the
future, for now the features (and workflow) for LUC will be as follows:
1) List available Fedora Products/Spins/Labs for the current release -
this will be updated automatically
2) Display additional information (text, screenshots, size, release
date) for each Product/Spin/Lab
3) Allow the user to download the image directly through the UI
4) Then transparently write the image (or any other ISO from the user's
drive) to a flash drive using dd (should work on Windows too)
5) When a flash drive that contains an image is inserted, show an option
to fix its partition table (writing ISOs with dd breaks it) and format it
to FAT32
Regarding 1 and 2: The information is now extracted from the websites like
getfedora.org, including links to the ISO downloads.
5 is not implemented yet - I'm going to write the backend code at least
for Linux today and then put up some makeshift UI before consulting and
smoothing the design with jimmac.
Regarding testing, there's quite a number of combinations possible and
most of them will require you to have a Mac and a "regular PC" both
probably (not mentioning dual-boot to Windows), as I assume these two are
not considered equivalent from our POV.
Anyway, when dd is used, it should be pretty error-proof - and testing LUC
and dd would be basically the same thing.
[1] https://github.com/lmacken/liveusb-creator/tree/feature/onlydd
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx
