Hi Chris, some of the outstanding entries in the TODO list in newui branch lack enough context. We mostly understand the summaries, but would like to know more about your ideas and directions you want to pursue. Can you please elaborate on some of the following items? (in the TODO itself or on the list). We can think about solutions ourselves, but as it is your design, you probably have ideas about how to make it properly and consistently. We would like to hear those. - 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? - 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? 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.. - 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. 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 ) - Wall of anaconda needs to be taken into account. I have no idea what this is supposed to mean... -- Martin Sivák msivak@xxxxxxxxxx Red Hat Czech Anaconda team / Brno, CZ _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
