On Fri, 2011-11-11 at 10:16 -0500, Chris Lumens wrote: > > 1) How certain does it look right now that the UI rewrite will go into > > F17? > > 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? > > 2) Is there a precise schedule for the UI rewrite to land, or is it more > > a case of 'we'll land it when it's done'? If the latter, do you have a > > hard date beyond which you would not land the rewrite, considering it to > > be too late? > > > > 3) Do you have any plans in place so far for testing the UI rewrite? Are > > there plans to get something buildable available early? Do you have any > > plans along the lines of making test images available, or do we have a > > blank slate to work from there at the moment? > > No, I have no schedule. As of last night, there is code in rawhide. > However it's all on a separate branch. On that branch, all the old UI > code is still there but just disabled so we boot into the new UI by > default. > > My plan is to continue working on the new UI on that branch, > periodically rebasing to pull in non-UI commits. When it's looking > solid (that is, when it actually does installs) I'll merge the branches. 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'd like to not plan for failure to deliver, but if that happens, we can > just not merge the branch. The existing UI will likely stagnate as a > result, but whatever. > > Testing - no code yet, but I have ideas. See > http://clumens.fedorapeople.org/UI/ui-tech-notes. Thanks for that, some useful stuff in there. Let us know if we can help out with anything. 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. :) > > 4) Have you taken into account all the use cases and required > > functionality implied in the release criteria and installation > > validation matrix in the re-design? > > We've done extensive talking about use cases, but have not referred to > the release criteria and test matrix. I suppose we should give it a > look. I'm sure there will be some things that need to change on either > side. 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. > > That's what I've got for now. Ultimately I'd like to work together to > > come up with a process so we can start testing the UI rewrite early and > > be able to test it continuously, with the hope that we can isolate > > potential problems early in the cycle and get them sorted before we > > start hitting the pre-release points. > > Since I'm taking the lead on this project, I have a vested interest in > making sure it's not a total disaster. So yeah, let's get talking about > how to test this now. > > I'll start with looking at cutlet and doing automatic composes for > internal testing. I wouldn't mind them getting distributed but right > now, there's really no point. The new UI doesn't let you do anything. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
