On Tue, 26 Jan 2016 18:19:41 +0100, Paul W. Frields <stickster(a)gmail.com>
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