Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 21, 2014, at 1:20 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote:


> It would probably be a Very
> Good Idea to get everyone with an interest - at least anaconda team, the
> product WGs (except possibly Cloud, depending on whether they intend to
> use anaconda in their deliverables at all), base WG, and fesco -
> together in some way to talk about it. devconf would've been great but
> it already happened. Flock would be great but it's too late. Should we
> try to set up some kind of special meeting / list / etherpad /
> wikipage / *something* where we can all talk it over?


Yes, please.

> Yet the installer design doesn't really communicate in any way that some
> paths through 'non-custom' install are more tested/reliable than others

Yes. Any many more paths through custom aren't tested, and likewise users don't know this.

Also my original estimate of 80 testable outcomes through Automatic/guided path is for single device. Anaconda permits selection of  multiple devices in this path. Therefore it's 160 testable outcomes with 2 devices.

The current four Partition Scheme choices have technical arguments for and against, but ultimately none significantly outweigh any other for the intended audience for this path, and it's non-obvious why the user would pick one versus another.

Option A: Eliminate the Partition Scheme pop-up menu. There is one recommended default.

Option B: Make the pop-up useful with Personas/Workload/Use Case options. Those selections cause a particular recommended layout to be used, layouts that are already tested via the Manual/custom partitioning path anyway because QA knows of certain commonly used layouts that really need to work. And also reduces dependency on custom partitioning

These aren't mutually exclusive, Option A could be implemented in the short term, and Option B later, and even expanded as well tested recommended paths "graduate" to the Guided listing.


> and the question of variant anacondas (whether any of the Products
> actually wants one, and if so, whether that's actually viable) pretty
> soon.

I agree it needs to be decided soon. I don't have an opinion which way it should go.

Option B above suggests Server and Workstation could have different Use Case options. I don't think it's necessary to have actual separate anacondas. A single anaconda package could permit variants. Depending on how the products are selected by the user:

At download time as unique media: anaconda is launched with a flag e.g. --server or --workstation or --cloud, that causes it to have the appropriate variant behavior. 

Within the installer UI: as a spoke within the hub, likewise causes the installer to be varied.

Post-install: doesn't require variation of the installer at all. Treat the installer strictly as a means of getting Fedora booting successfully. Shave the ice, then flavor it.


Chris Murphy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list




[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux