Dear Technical Committee,
after reading the CTTE meeting log from 2017-01-26 [1], I feel a bit
disappointed. As far as I understand (I am not a long-term DD yet),
the Technical Committee has the task to decide items, where a
consensus could not be reached. Here, this is obviously the case, as
one can easily see from the (longish) history of this bug. If you are
going to just close this bug asking us to "talk to each other", please
at least give the direction where a possible compromise could be
achieved. I don't see it for the moment at least, and I would be felt
left alone with just this general recommendation. I would probably try
to reach a compromise with KiBi, but if that fails (which I would
suspect after he removed the Blends tasks from the installer) I would
re-open this bug for CTTE and again ask for a decision.
Here is a try to summarize the arguments for the different options that
you were asked to decide. I admit that this is biased, since I am a
strong proponent of one of the solutions, but hopefully I didn't forget
any counter argument brought here as well. Please remember that the
whole discussion is about the inclusion into the next stable release;
for the time after Stretch the compromise outlined in 1.2 below seems
to convince most of the participants.
The bug raised two questions on which the CTTE was asked to decide:
1. Shall the Blends selection menu be a (default) part of the
installer for Debian Stretch?
2. Shall the Blends selection menu be maintained by the Debian Blends
team or by the Debian Installer team?
1. Blends selection during installer
====================================
As pointed out several times during the discussion, this is the most
important disagreement here. Four options were presented during the
discussion:
1.1 Keep the (pre-RC) selection in the installer
------------------------------------------------
This means mainly that the tasksel step would present the following menu:
[ ] Debian Desktop Environment
[ ] ... Gnome
[ ] ... Xfce
[ ] ... KDE
[ ] ... Cinnamon
[ ] ... MATE
[ ] ... LXDE
[ ] ... LXQt
[ ] web server
[ ] print server
[ ] SSH server
[ ] standard system utilities
[ ] Special tasks
[ ] ... astronomy (Debian Astro)
[ ] ... games and fun (Debian Games)
[ ] ... life sciences and medicine (Debian Med)
The main argument against this was that this would confuse the users,
based on common usability principles. Also, it puts the "standard
system utilities" somewhere in the middle, where it does not make
sense.
Some points were raised against this argument:
* They originally covered only the first version, after which the
appeareance was changed significantly (limiting the number of
entries, and use better descriptions). After the change, there
were no further complaints (except this current bug).
* The whole menu is already confusing: it is f.e. not clear to an
average user what "standard system utilities" means (its position
can still be changed). The desktop environment entries are not
understandable for an unexperienced user either.
* Despite their argument that additional entries would confuse
users, the debian-installer team decided to still add the "LXQt"
entry, which makes the argument questionable,
* No case of user confusion was documented while the installer
included the Pure Blends in the form shown above
1.2 Additional selection screen with "More options"
---------------------------------------------------
This was proposed by Phil: before the screen shown in 1.1, implement a
screen, looking mainly like this:
<*> standard desktop
< > Show me more options
While this was noted as a possible compromise, actually increasing the
usability by hiding extra options from the average user, it was
rejected by KiBi as being too late now for Stretch. Independent of the
solution chosen in Stretch, it may be however a compromise later.
1.3 Create separate images for each blend
-----------------------------------------
This was proposed by Holger Levsen in the opening of the
bug. Advantages would be that one could just tell people to download a
specific image for their use, while others were not confronted with it.
As disadvantages however were raised:
* This multiplies the number of images we currently have by the
number of blends. It may confuse people having to select between
more images, and increases the maintenance load.
* It will confuse people wanting to install two blends at the same time
* People may think that they have to re-install if they want to switch
to or from a Pure Blend
This proposal was then not further pursued.
1.4 Leave the Blends completely out of the installation process
---------------------------------------------------------------
This was the situation before the Blends tasks were installed, and is
the case for the current (RC1) installer.
2. Maintenance of the blends tasks menu
=======================================
2.1 Maintenance by the Debian Installer team
--------------------------------------------
This would keep the full control of the menu in the hands of
d-i. Changed could be done by bug reports, but always require action
of d-i, which is already overloaded.
2.2 Maintenance by the Debian Blends team
-----------------------------------------
The Blends team is dedicated to create the common infrastructure for
the Debian Pure Blends. As such, it is crosslinked to the individual
blends teams and has the best knowledge to specify the exact entries
for the installer. Remaining problems seen by d-i (or anyone else)
could be done by bug reports. This option implies for the
"blends-tasks" package the priority "important", which was considered
a policy violation by Holger Levsen.
Please consider taking the responsibility to actually do a decision
on these items for Debian Stretch, or (better) moderate the discussion
so that we can reach a compromise here.
Best regards
Ole
[1]
http://meetbot.debian.net/debian-ctte/2017/debian-ctte.2017-01-26-18.03.log.html
