On Feb 21, 2014, at 1:20 PM, Adam Williamson <awilliam(a)redhat.com> 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