> > I plan on having at least a simple but usable new UI in F17. It may > > lack some of the bells and whistles in the mockups, and as previously > > mentioned it may lack a text mode interface. I would think that by F18, > > that kind of stuff would be present. > > Okay. So it's possible we may have some functional regressions in F17, > right? Yeah. I'd say there's at least a 75% chance of no text mode in F17, but we should still have vnc. And, we have plans for producing a text mode interface that won't look like crap over a serial console so we'll at least be taking it away with the intention of putting back in something better. I guess we had better start preparing people for that now. Other things in the current design I see as in danger of not making F17 would be the filter UI (I know people would be really broken up over that) and the firstbootish stuff on the second hub. It's also possible we'll clobber something else that a handful of people were using like autoscreenshot or the debug button, and those might go totally unnoticed until a bug gets filed. > At what point do you think it'd start being useful to have testing and > feedback from QA on the new UI? At around the point where you want to do > the merge (i.e. when the new UI can at least do a straight-through > install)? If so then that's good, as we don't need to do much besides > ensure we can iterate images rapidly after the merge. I think we at least need to be able to do an autopart+default package selection install, plus the typical network and locale customizations before it makes sense to have people testing it. Otherwise, you're just looking at something that doesn't do anything. My tentative hope is to have everything through the first hub except for storage done by the end of the calendar year, and perhaps a rough draft of storage for FUDCon. But don't hold me to it. > Thanks for that, some useful stuff in there. Let us know if we can help > out with anything. Anything you want to take a look at would be great. I'm buried in sorting out code infrastructure tenuously related to making the upgrade screen appear or not. Once that works, I plan on taking a look at that whole list and seeing where the UI stands against each item. > One random note on that: "This is the perfect time to either drastically > rethink or completely do away with our package selection UI" - I suspect > you'll want to at least think along the lines of keeping enough to let > people pick their desktop at install time, or else we'll have a major > riot, I think. :) We have plans for a useful but simplified package selection UI. They're in the mockups somewhere. > Yup. I don't mean to imply that anything at all is non-negotiable - I > just want to make sure all those requirements and use cases we've built > up over the years are considered, so we don't simply _forget_ about > something. Considering something and then deciding we don't want to > allow it any more is absolutely fine, of course. It's highly likely things will be forgotten. We just need to make sure we can add back in what's important without too much pain later. > I always like to think from the point of view of 'why not' rather than > 'why' when it comes to spreading test images around. It's sometimes the > case that you're pleasantly surprised by how sophisticated someone > 'outside the firewall' is, in terms of being able to give you useful > testing / feedback on barely-usable code :) As long as it's not for some > reason massively easier to keep stuff private, I think we may as well > just have all test images and so on put up somewhere accessible, like we > do with TCs and RCs. We don't need to advertise them broadly and tell > people to use them, but we can mention them here and on test list so the > hard core can start taking a look early. > > This also avoids the problem where you design a process that's only any > good for building / releasing images in private, and then realize later > down the road that you'd prefer more people to have access to them. I'm hesitant to make it too easy to test for now given the elementary state of things. I really don't want bug reports, because I know nothing's implemented and what is implemented is horribly broken and kind of ugly. I expect this to be the situation for the next month. The main reason I want to set up automatic compositions locally is so the rest of the anaconda team has something to work against instead of wasting their time running pungi, too. Once anaconda can actually do something, then sure we'll start opening the testing wider and wider. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
