On Thu, Nov 12, 2009 at 2:40 PM, Roman Shtylman <[email protected]> wrote: > Overall, I like the idea of a more fault tolerant installer... who wouldn't :)
Indeed. As Lucid is a Long Term Support release, I'm very keen on really giving some thought to better handling failures such as this, and either recovering from them automatically or providing a clear path for the user to do so. I'd also like to add more code to protect the users from feeding bad data into the installer (ubiquity/validation.py), continuing Colin's work on static testing, adding automated and unit testing, and so on. Further ideas and code welcome :). For example, today I finished up a "retry grub installation" dialog for the GTK frontend that will come up when grub-installer fails. By the way, it would be wonderful if you could port that to the KDE frontend whenever you have some free time. > Out of the three options that Evan presented, I have concerns about > option #2 (install then upgrade). To me this feels like back-peddling > and basically giving off the impression that this release is not > complete enough (since the installer couldn't even work). They may be > less likely to update once they go back and install the previous > version. It also may require them to go download a whole new disk > image (a concern for some). The installer didn't work. We shouldn't shy away from that. This is all about giving them something more than a shrug and apology. While I can empathize with your concerns, if a previous release could work for them, I don't believe we should discourage it because it's not an ideal path. I think if downloading a new image is a concern, they wont do it. But they may not be aware that they can easily upgrade between Ubuntu releases, and that it's free. So I think it's important that we present the upgrading option. > The other two options are more proactive and suggest what the user can > do in the immediate sense to solve their problem. Option #1 I believe > to be the best. We may even want to remind the user what step they > were on and maybe which set of options they have selected to that > point? It might refresh their memory and possibly make any bug report > their choose to file more complete. Just to be clear, my intention is for the dialog to present all the options. The difficulty I see in incorporating what page the user was on when the install failed into the retry the install message is that it's likely they were already at install.py (the main progress bar, for the unfamiliar), and thus it's unclear what particular component caused a failure. Of course, we could mark this as we progress through scripts/install.py, but that would leave copy_all as a grey area (which admittedly, it would be anyway). Any suggestion on how we would word this? Thanks for the input; it's very much appreciated. -- Ubuntu-installer mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-installer
