On May 21, 2009, at 10:28 AM, Karen Tung wrote: > Hi Thea, > > I have a few comments inline. > > > Thea Gab wrote: >> >> >> >> 2. Ensure adequate testing is performed >> >> What defines "adequate" testing? In terms of your involvement with >> this project, what degree of testing will you be doing? >> >> >> We meant this requirement more as coordination with the QE's and >> test engineers, but we also plan to do our own testing of our code >> by trying out our install on different computers, using different >> options, etc. We will change this on the wiki to clarify. > I think it will be useful to list out the details of your test > cases, including the different input > parameters, and the expected results. > This could include both normal code path, edge cases, failure cases, > etc. > That way, people can see what tests are done. Even if you don't > plan to test a particular > case yourself, it would still be useful to write them out, so, it is > understood that the code is > not tested in those cases. >>
Work with Andre Molyneux on this. They should be driving the general testing and helping you define what's needed. >> >> >> 3. Make sure that ncurses interface is user-friendly >> >> >> *Secondary:* >> >> 1. Runs on SPARC architecture >> >> 2. Line-by-line interface >> >> 3. Network installation >> >> >> *Use Cases:* >> >> 1. User has SPARC machine and wishes to install OpenSolaris by >> inserting a CD and selecting configuration options through a >> console. >> >> 2. User has x86 machine and wishes to install OpenSolaris, but >> does not have enough memory to run GNOME. User inserts the >> text-based install CD. >> >> 3. User has x86 machine but graphics card is not supported by >> OpenSolaris, so they run the text-based installer in order to >> install OpenSolaris. >> > These sounds like you are describing the target users of the text- > base install CD. Is that the intention? >> >> >> 4. User starts install (situations 1-3) and the install runs >> to completion with no problems. At the end the user is given >> back control of the terminal from which they can explore the >> system or reboot. >> >> What are the reasons for supporting this use case? Or rather, for >> drawing attention to it as desired behavior vs. automatically >> rebooting, for example? >> >> >> We included this case just to indicate a normal flow of events >> after the installation starts. It was suggested to us that we give >> the user the option to cancel out of the automatic reboot, so they >> can look at the log files and other aspects of the system before >> the reboot occurs. We will reword this to be a little more clear. > I think I am confused like Keith as well, probably because 1-3 is > describing who is going to > use the text installer, and this bullet point is about "a feature" > that will be included in the text installer. > If I understand you correctly, the feature is allowing users to exit > the text installer at the end of an install, so > they can look at log files and check the system...etc... So, this > info would probably fit better in > the feature section of your doc. > > Thanks, > > --Karen > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
