Hi Keith, Thanks for all your responses. I have a few more questions/comments below.
Keith Mitchell wrote: > >> >> 2.1.6: In the functional spec(section 3.2), it says that when the user >> exit the installer, it will display a small menu of choices. In this >> design >> specification, there's no discussion at all about how that small menu >> is displayed? What program is called to display that menu...etc.. >> Please elaborate on that. > > See section 2.8. I read section 2.8. From that, I understand that the small menu is displayed by the application/text-installer:default instance. What I still have a question about is when the user choose "shell prompt", and when they are done with using the shell, how do they get back to the menu? > >> >> 2.1.7: When reporting errors, will the error be reported >> immediately? ie: If I type an invalid value >> in input field1, will I be immediately warn about the error as I move >> my focus to another >> input field? Or will all the error checking be done when I try to >> click next? >> Also, will I be allow to go to the next screen if I got invalid errors? >> Please clarify in this section. > > Please see the UI spec. I will point to the UI spec again here. > Can you point me at exactly where in the UI spec have this info? I am not able to find information related to this. >> >> 2.1.7: Can you give an example on how one will get to this situation >> of making an invalid selection? If we are giving people choices, is it >> possible to always only give them valid choices? > > Most invalid selections are impossible situations (for example, the UI > spec calls for not allowing the user to even highlight a disk that is > not at least as large as the minimum size). The only example of > invalid selection I can think of would be trying to continue past the > partition screen without creating a Solaris partition. > For this situation, would it make sense to disable the ability to choose "next" until a Solaris partition is created? > >> >> 2.3.2.4: why is hostname part of UserInfo? That is not related to a >> user. > > Moving this to NetworkInfo. > > While I'm here, it makes more sense to change UserInfo to just be name > and password. InstallationProfile will have an array of UserInfo (in > the case of the Text Installer, only 2 UserInfo's will be in the array > - one for "root" and one for a single additional user). > I agree that having an "UserInfo" object with username and password is better. It is more extensible later in case other user attributes need to be added. I think we should add one more attribute to the UserInfo object. A flag or boolean to indicate whether this user is a regular user or a role. If people don't specify a user, the root user will be a regular user, and if they specify a user, the root user will be a role. The "rule" to determine whether the root user should be a role or not is determined by the type of installer, so, it makes sense to fill in that field when UserInfo object is created. >> >> 2.4 and 2.5: There is the Required Library Functionality and >> Non-Library functionality >> section. Why group them as such? Looks like some of the functions >> in both sections >> could be used by other installer as well. Will functions from these >> 2 sections be >> delivered as separate libraries or the same library? > > Functions in 2.4 Required Library Functionality should and will be > made available to other installers. Functions in 2.5 Non-Library > Functionality will be implemented and private to the Text Installer. This makes sense to me now. Can you add this to the spec, in case other people have the same confusion as me. > In the case of get_[min|recommended]_install_size, this data is read > from the .image_info file and is very small code, so it was decided > that it would be implemented internally via Python rather than going > through the overhead of a library call (that would likely dive through > a bridge to C code). Agreed that it is better to implement this directly in Python. This function should also be used by other installer, such as the GUI, so, should it be in the shared library? > > >> >> 2.5.5.4: Does "prep_transfer" include the actual transfer of bits? >> Based on the description >> in 2.5.8, I think so, but I think the choice of name is not so good. > > Yes, it's a bad name. I was trying to avoid a naming clash with > libti's do_transfer call, but prep_transfer is a misleading name. > Would "perform_transfer" be preferable? Yes, that is better. > >> >> 2.8.3: Since the grub menu will only contain 1 entry, the exiting >> grub_setup.py finalizer >> script will need to be modified. At this time, this script will >> insert at least 3 entries >> into the grub menu. > > The default value will be set, and timeout set to 0. In this way, it > is irrelevant how many GRUB entries are on the disk. However, I'd be > happy to file a separate RFE to enhance grub_setup.py to make adding > those entries optional - but strictly speaking, it is unimportant. > OK. Actually, there's no need to file a separate RFE. Alok filed one requesting similar feature: 10750 Thanks, --Karen
