> - Custom partitioning needs to be revisited, then written. > - Disk tug-o-war needs to be written. > - Test handling of inconsistent LVM/RAID, and uninitialized disks. > > If I followed correctly, this is what you are doing ATM, right? I am currently looking at the first one, and I'll look at the second one at some point soon too. The third one, I've got no ideas on. > - Install hub needs to be skipped if all spokes are completed on a kickstart install. > How to handle the fact that spokes may only be ready once they're finished downloading? > > This would be handled in Hub's refresh method I assume. Can we detect > that a spoke is still downloading? I mean, do we have a "spoke ready" > message? Much of this might actually already be done. See the bottom of _update_spokes in hubs/__init__.py. If everything's done before the hub is even displayed (is this even possible? perhaps just for media installs) then we need something clever in GraphicalUserInterface.setup. > We might just show the Hub screen with information about the > ongoing operation and then continue once everything is ready && > completed. I am not sure about whether we should allow the user to > make any changes while in ks mode, we used to ask for stuff we didn't > get, so we probably should.. We should definitely allow making changes. With the new hub and spoke model, we're even letting the user do more than we did in the previous installer, since they can go and change anything not just stuff they didn't fill in. > - Update exception handling. This requires updating python-meh to use gtk3, > which also requires updating firstboot and s-c-ks to gtk3. I want to turn > s-c-ks into an anaconda wrapper first, though. > > Anything we can help with (the gtk port is obvious)? How do you > envision the wrapper to work and interact with newui anaconda? Do we > still want s-c-ks? I thought we are about to kill it and use the newui > in standalone mode. I am still planning on killing s-c-ks, but I don't think that's going to happen for F18 either. So, we're going to need to come up with another plan if we want graphical bug reporting in anaconda. I guess the easiest thing to do would be to just remove python-meh code from s-c-ks so that dependency doesn't exist anymore. We do not have a design for how exn handling should look in the newui. We'll talk about that. If anyone wants to get started looking at the code changes required, go right ahead. > And what about firstboot and anaconda widgets? Do we still plan to > implement interoperability there? (I am asking because there is > another project seeking to replace firstboot - > https://fedoraproject.org/wiki/Features/InitialExperience ) I don't know about this one yet. It's my expectation that we won't get around to doing the firstboot things in the UI until F19, so there's some time to figure it out. > - Wall of anaconda needs to be taken into account. > > I have no idea what this is supposed to mean... http://blog.linuxgrrl.com/2011/12/21/the-wall-of-anaconda/ - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
