[Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes

[Douglas McClendon]

Douglas McClendon wrote:
> Rahul Sundaram wrote:
>> Douglas McClendon wrote: 
> 
>>> How about we split livecd-iso-to-disk into its own package, 
>>> specifically because of the use-case scenario of a user just wanting 
>>> to put their newly downloaded f8-livecd on usb, without any need or 
>>> interest in full-blown livecd-creation?
>>>
>>> And install it by default, perhaps even in the minimal base spin config?
>>
>> This sounds like a good idea especially if we provide a menu option to 
>> make this feature more visible to users and reviewers who don't read 
>> the release notes which is unfortunately quite a lot.
> 
> I could throw together a ghetto zenity gui pretty quickly.  The only 
> user interaction is
> 
> a) selecting iso
>   - for the gui, this could be handled by zenity file-selection, or the 
> default would be to use /dev/live if it exists (i.e. /dev/live is the 
> accessible block device representing the currently booted livecd).

and d) for DUH... selecting the partition/device, which could be a 
selection amongst /dev/disk/by-id/

> b) bypassing checkisomd5 if it fails
>   - this is easily enough a zenity question, or perhaps just make it a 
> pure failure case for the gui
> 
> c) livecd-iso-to-disk result text output, either success, or failure for 
> some reason.  Easy enough to dump to a zenity dialog.
> 
> I'm curious, what kind of deadlines should I be thinking about for this 
> and other livecd related things.
> 
> I.e. the f8 devel freeze is Oct 4th, as of f8t3 release.  But then there 
> is an f8t3 devel freeze as of Sept 25th (along with translation freeze).
> 
> What sort of development is considered acceptable between those two dates?
> 
> Obviously I would like to get anything in by say... tonight, so that 
> Jeremy has time to decide to accept it and commit it  before tuesday, 
> and then not try to get anything in after that.
> 
> And would this theoretical gui livecd-iso-to-disk separate package fall 
> outside the scope of even the oct-4th devel freeze, because it is a 
> 'new' package?
> 
> -dmc
>