Re: [RFC] New installer-settings component - please test and comment!

2009-01-20 Thread Frans Pop
Below a reply to a very old post from Joey [1] to which I should have 
replied then, but never got around to. I've quoted his mail in full for 
context.

[1] http://lists.debian.org/debian-boot/2008/05/msg00345.html

On Thursday 08 May 2008, Joey Hess wrote:
 A long, long time ago I proposed changing the main menu into a kind of
 list of settings like this.

   Language: English
   Location: United States
   Network: autoconfigure
   Disk: autopartition entire disk (hda1)
   Users: root, joey
   Software: desktop, print-server
   Grub: install to MBR, no other OS
   Finish installation

I get the idea, but I don't really see the implementation. For a lot of 
components I just don't see how you could usefully translate them into a 
value and there's also the problem of limited line length.

 Select a menu item to configure it, thereby running the menu item
 at medium priority, or skip over it if the default setting looks good
 (and skipped over menu items would run noninteractively at high[1]
 priority as needed to satisfy dependencies).

 Once you have such a menu, it's easy to add things to it, without them
 getting in the way unduely. As long as there arn't *too* many.

   Language: English
   Location: United States
   Mouse: PS/2
   Theme: foo
   Network: autoconfigure
   Disk: hda1, autopartition entire disk
   Users: root, joey
   Software: desktop
   Grub: no other OS
   Finish installation

   Expert mode: disabled
   Rescue mode: disabled

 Of course, submenus could also conceivably branch off of this.

installer-settings essentially implements a submenu. I also feel that the 
implementation I have now is one that does not get in the way, especially 
since it is only really used if the user selects expert mode, so 
basically he gets what he asks for.

For the graphical installer it would be great if an alternative menu bar 
kind of interface could be implemented.

 Frans Pop wrote:
  Overview of potential settings
  --
  * General
- show expert questions (in early)
- debconf priority (in menu)
- rescue mode (in early/additional)
- frontend theme
- mouse support (device/protocol/left-handed) (in early/menu)

 Having these things in a submenu makes sense, I think, both in the
 current installer, and in the context of the above wild idea.

  * Hardware support
- SATA RAID
- multipath
- PCMCIA support (could help avoid asking multiple times!)
  * Networking
- PPPoE support (in early)
- type of configuration (none/static/dhcp)
- allow unauthenticated (?)
  * Installed system
- use SUDO instead of root account
- create first user
  * Debian settings (or Package management)
- use security (?)
- use volatile (?)
- use contrib (?)
- use non-free (?)
  * Advanced
- keep regular virtual consoles (sercon installs)
- eject CD
- halt/poweroff system instead of reboot

 I'm not convinced that it makes sense to have a menu with these things
 on it, rather than just asking the questions at relevant times with
 appropriate priorities.

For a number of them I'm inclined to agree. We will have to be very 
careful about which we do and which we don't select. But I also feel 
quite strongly about keeping the number of times to hit enter for a full 
install as low as possible.

And there are some options that IMO really should be more easily 
accessible to users, *without* forcing them to go through _all_ possible 
dialogs and permutations. One example is the eject CD option.
This really does cause problems sometimes, but not enough to warrant an 
extra dialog during finish-install warning that the CD is about to be 
ejected. Currently the only way to prevent CD ejection is using a boot 
option, which most users don't know about and which you have to remember 
at a time that your mind just isn't on that stage of the installation.
Having it as a setting Eject CD at end of install means that users will 
both have an easy way to change it _and_ have a visual reminder.

 To what extent are the problems this is trying
 to solve due to us having gotten into the bad habit of adding debconf
 settings but never actually displaying a question for them?

AFAIK we've only done that for functionality that is still experimental. 
It's always been the intention to make them properly accessible, or to 
support them by default, once better implemented. ATM both dmraid and 
multipath still rely on very crude bootloader installer support.

More general, for support of things like PPPoE, dmraid and multipath the 
installer can IMO go two ways:
1) support by default, which means additional memory usage and
   potential failure modes;
2) offer it as optional functionality.

Given that all three are only relevant for a fairly small subset of users, 
I feel that the second option is quite realistic. But neither forcing 
those users to the current expert mode 

Re: [RFC] New installer-settings component - please test and comment!

2009-01-19 Thread Frans Pop
On Tuesday 13 January 2009, Frans Pop wrote:
 Over the past months I've been working on a new component that allows
 to change settings for the installer. Main intention is to improve
 the flexibility of the installer and the user experience.

Not that much feedback, but I guess that was to be expected :-(
So, let me explain what this is all about.

There are several things that I've never really liked about the 
current expert mode:
* default install offers too few options for quite a few users, but
  expert mode immediately goes to the lowest possible level: there
  is no graceful way to select intermediate levels
* medium priority (which I've personally always preferred over low
  priority) is effectively inaccessible to users and unused in
  practice
* showing the menu is coupled hard to priority levels, even though for
  debugging it would be quite nice if you could run an install at high
  prio but _with_ menu, and for expert installs it would be quite nice
  if you could run at medium prio but _without_ menu (as users in
  principle have no need to skip installation steps or change the order
  of installation steps)

Another issue is that we do have some specific options in D-I (PPPoE, 
dmraid, multipath) that I would personally like to see remain as optional 
features, but we currently don't have any user-friendly way to activate 
support for such option.

installer-settings is intended to solve all of these issues.

Flexible and gradual expert support
=
In its current implementation installer-settings does *not* change default 
installs: no extra dialogs, no changes in the installation order.
Only if you back up to the main menu you will see a new option Installer 
settings that allows to change settings that are relevant at that point 
of the installation. It also allows to change the debconf priority and 
whether or not to display the main menu.

Expert installs are changed. A lot!

* Instead of 'priority=low' the syslinux config will now add
  'expert=true'. In other words: when the installer is started the
  priority is *high*, just as for a default install.
* localechooser checks this expert setting and if set displays its
  medium prio dialogs (e.g. locale selection) at high priority.
* After locale and keyboard selection a early installer settings
  dialog is displayed. This allows the user to select the expert
  level at which he wishes to continue the installation.
* After anna a second installer settings dialog is displayed.
  This will allow to change settings for components that were not
  available before anna and settings which will never be relevant
  during the early stages of the installation.

All this results in the following modes being available to users:
1) automated/preseeded install (critical priority): installer-settings
   is disabled
2) default install
3) expert mode:
   a) default level: remain at high priority, but with option to
  change settings (for example: to activate dmraid support)
   b) same as a) but with main menu displayed between components
   c) advanced level: medium priority, without main menu (by default
  it is displayed, but it can now be disabled)
   d) same as c) but with main menu
   e) could be implemented as either expert level or as debug level;
  in either case: low priority (menu will always be displayed)
4) rescue mode

When this is implemented the priority level of some dialogs should 
probably be adjusted. For example: the grub password dialog should be 
displayed at medium priority.
Some existing dialogs could possibly be implemented as a setting, in 
which case the priority of the dialog itself should be lowered to low 
priority.

Implementation
==
installer-settings has a drop-in structure to add settings somewhat 
similar to partman. This means that the code that implements an 
individual setting can be part of the relevant component. Example: the 
settings for dmraid and multipath are implemented in disk-detect.

See /usr/lib/settings/*/ in the test images for examples.

installer-settings itself has absolutely no state info: it exclusively 
uses state (debconf values) from the component to which a setting 
belongs. This means that it does not interfere in any way with for 
example preseeding.

installer-settings itself consists of 4 udebs:
- installer-settings: core functionality
- settings-early: provides the settings menu entry after
  locale/kbd-chooser
- settings-anna: provides the settings menu entry after anna
- settings-menu: provides the permanent optional settings menu entry

Settings can be defined very flexibly:
- limit to settings-early/anna/menu
- only show at certain debconf priorities
- only show based on scripted logic (choices script)
- warn or don't show if certain installation steps have already been run

Settings can be coded to be changed either by just hitting enter on 
them, or by displaying a dialog.

Size impact
---
There is some size impact, 

Re: [RFC] New installer-settings component - please test and comment!

2009-01-17 Thread Frans Pop
On Thursday 15 January 2009, Frank Lin PIAT wrote:
 Being able to easily (and really), switch from expert mode to standard
 mode is really great for those who just needs expert mode in the firsts
 steps.

Hmmm again. That is not really what happens, especially not if you compare 
it to the current situation.

If you have time, could you try it a bit more extensively and maybe 
describe a bit how you think expert mode now works with the test images?

The same request for others: I'm really interested to find out if the new 
concept feels natural to users who do not have it explained to them 
first.

Some hints:
- default installation is basically unchanged; only difference is if you
  back up to the menu
- expert installation really is completely different from current
  situation, please give it a try!
- the option to enable dmraid/multipath support is somewhat separate from
  the change in the expert mode concept

Images available at: http://people.debian.org/~fjp/tmp/d-i/settings/

I will send an explanation of the concept at the end of the weekend.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: [RFC] New installer-settings component - please test and comment!

2009-01-14 Thread Frank Lin PIAT
On Tue, 2009-01-13 at 23:06 +0100, Frans Pop wrote:
 On Tuesday 13 January 2009, Frank Lin PIAT wrote:
  If I understand correctly, the idea is to be able to be able to switch
  *easily*  between standard and expert mode during the installation.
  This is a nice.
 
 Hmm. Have you tried booting in expert mode?

I have quickly tested the updated images... The behaviour of the
bug-free images is very much sensible ;)

I like the Using expert mode isn't recommended notice.

I still like the possibility to opt-out some DI steps.

Being able to easily (and really), switch from expert mode to standard
mode is really great for those who just needs expert mode in the firsts
steps.

I didn't fount any problem/drawback in this quick test.

Franklin


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



[RFC] New installer-settings component - please test and comment!

2009-01-13 Thread Frans Pop
Hi all,

Over the past months I've been working on a new component that allows to 
change settings for the installer. Main intention is to improve the 
flexibility of the installer and the user experience.

I'm now at the point where I'm happy with the framework and would like to 
get some comments from others.

I'm not going to say too much about how it works. Just try it!

Test images for amd64 and i386 (newt frontend only) are available from:
http://people.debian.org/~fjp/tmp/d-i/settings/

What I will say is:
* it completely changes the concept of expert mode
* you can now have the main menu displayed optionally for both
  high and medium prio installs!
* for this demo only a limited number of settings are available:
  - changing the installation level
  - activating support for dmraid and multipath
* demo images use vga=788 for newt frontend

For the demo there are a few implementation differences between the 
activation of dmraid and multipath to show the versatility. Just try 
changing those settings at different points during an installation.

I'm looking forward to your comments and thoughts.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.


Re: [RFC] New installer-settings component - please test and comment!

2009-01-13 Thread Frank Lin PIAT
Hello Frans,

On Tue, 2009-01-13 at 12:06 +0100, Frans Pop wrote:
 
 Over the past months I've been working on a new component that allows to 
 change settings for the installer. [..]

 What I will say is:
 * it completely changes the concept of expert mode

If I understand correctly, the idea is to be able to be able to switch
*easily*  between standard and expert mode during the installation. This
is a nice.
I took me a few minutes to understand how that's supposed to work (I
though it was a bug or an incomplete implementation whereas it is just a
matter of changing the wording)

 * you can now have the main menu displayed optionally for both
   high and medium prio installs!

Being able to opt-in or opt-out some steps (like dmraid) is a great
idea. (would it be possible to switch between [standard|expert|skip]?)

 * for this demo only a limited number of settings are available:
   - changing the installation level
   - activating support for dmraid and multipath
 * demo images use vga=788 for newt frontend
 
 For the demo there are a few implementation differences between the 
 activation of dmraid and multipath to show the versatility. Just try 
 changing those settings at different points during an installation.

I haven't tested it yet.

I'll sleep on it, and let you know If I have more ideas.

Franklin



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: [RFC] New installer-settings component - please test and comment!

2009-01-13 Thread Frans Pop
On Tuesday 13 January 2009, Frank Lin PIAT wrote:
 If I understand correctly, the idea is to be able to be able to switch
 *easily*  between standard and expert mode during the installation.
 This is a nice.

Hmm. Have you tried booting in expert mode?


signature.asc
Description: This is a digitally signed message part.


Re: [RFC] New installer-settings component - please test and comment!

2009-01-13 Thread Frans Pop
On Tuesday 13 January 2009, Frans Pop wrote:
 Test images for amd64 and i386 (newt frontend only) are available from:
 http://people.debian.org/~fjp/tmp/d-i/settings/

Major OOPS!

I just realize that the image for i386 is completely broken as some of the 
modified udebs are not included. I'll fix that and upload a new image.
The amd64 image is correct.

Sorry...


signature.asc
Description: This is a digitally signed message part.


Re: [RFC] New installer-settings component - please test and comment!

2009-01-13 Thread Frans Pop
On Tuesday 13 January 2009, Frans Pop wrote:
 On Tuesday 13 January 2009, Frans Pop wrote:
  Test images for amd64 and i386 (newt frontend only) are available
  from: http://people.debian.org/~fjp/tmp/d-i/settings/

 I just realize that the image for i386 is completely broken as some of
 the modified udebs are not included.

The image available now is correct. Sorry for any inconvenience or 
confusion this may have caused.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.