On Feb 21, 2014, at 1:20 PM, Adam Williamson <awill...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
