[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-desktop-list
Subject:    Re: Dropping i686 media for F24
From:       Martin Bříza <mbriza () redhat ! com>
Date:       2016-01-27 10:14:58
Message-ID: op.ybv6q8c3trc8xl () dhcp-4-153 ! brq ! redhat ! com
[Download RAW message or body]

On Tue, 26 Jan 2016 18:19:41 +0100, Paul W. Frields <stickster@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
--
desktop mailing list
desktop@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
[prev in list] [next in list] [prev in thread] [next in thread]