Debian Bug report logs - #846002
blends-tasks must not be priority:important

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Sun, 27 Nov 2016 17:38:27 +0100

[Message part 1 (text/plain, inline)]

Source: blends
Version: 0.6.94
Severity: serious
Tags: d-i
Justification: Policy 2.5 and breaking another package

Hi,

I'm sorry, but the current implementation of installing Blends from Debian
images is simply not acceptable, as in, it completely breaks the UI of
debian-installer thus the severity. (It's also an unacceptable policy
violation, see below.)

For those wondering what the current implementation looks like, have a look at
	https://lists.debian.org/debian-blends/2016/05/pngVVl6XLXLxZ.png 

In words: several blends have been added to the tasksel menu (the one which
asks which tasks should be installed, "default", "standard", "desktop",
"ssh-server", etc.)

The ascii version of the above linked screenshot looks like this:

--begin--

At the moment, only the core of the system is installed. To tune the system to your needs, you can
choose to install one or more of the following predefined collections of software.
Choon software to install.'
o webserver                                              _
0 printserver
O SSHserver
0 standard system utilities
O Debian Pure Blends
  o  Deb;
O.  DebianEdu
O.  DebianEzGa
O.  DebianGames
O.  DebianGIS
O.  Hamradia
O.  DebianJunior
O.  DebianMed
O.  DebianMultimedia
O ... Debian Science

-- end --

This aint acceptable for a debian-installer for the reasons laid out in #758116. 

Look for those two mails from bubulle in that bug, they explain very well, that+why 
the current implementation is a *no go*:
	https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#320
	https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#340

Technically this was implemented by setting the binary package blends-tasks to 
prio: important, which needs to be reverted to fix the current tasksel mess.

Also, setting blends-tasks to priority:important is a policy violation, please
read https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
- packages with priority:important are installed by default, and there is 
*no* need (as it doesnt make sense, it's not useful) to have blends-tasks
installed by default on each and every Debian system.

(I'm sorry if describing https://lists.debian.org/debian-blends/2016/05/pngVVl6XLXLxZ.png
as a mess hurts some people. I dont know a better way to put it.)


So how to fix this *and* allow Debian blends be installed easily from
official Debian media?


My idea to implement official Debian which can be used to install blends is to
introduce "flavors" (or spins or whatever, just a new term, to not overload old
ones), which basically are themed netinstall images.

For illustration, these are some netinstall image _flavors_/_spins_ I have in mind:

	debian-classic / textmode d-i
	debian-graphical installer
	blends selection (graphical)
	debian-edu blend (graphical)
	debian-parl blend (graphical)
	debian-speakup (textmode d-i with speech enabled by default)
	…


The idea is, that these images have the *same features* (and packages), the
differences are just which the preselected default in the boot menu.

So they all have the same boot menu too, and it's possible to install each
and every flavor by manually choosing a different boot menu.

This has several benefits:
- it's possible to tell people "download $this iso to install $this type of
  Debian"
- without giving them congnitive stress by presenting them choices they dont
  understand
- the boot menu is also not translatetable, so having choices there wont help
  many users. 
- this can be implemented for stretch. Major changes (especially ones
  requiring translations) are not likely to happen anymore, so this is one
  way to have official Debian blends images *at all*. (As said, the current
  implementation is not acceptable.)
- the current implementation is also useless for Debian Edu and at least 
  very inconvinient for other "non-standalone" blends (those who also need the
  desktop task to be installed), not all blends are self contained. Debian
  Edu OTOH is blend which comes in several variations. (see 
  https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-stretch-manual-images/08-Choose_Debian_Edu_profile.png
  to understand that "one type of Debian Edu installs" is not enough.)


The actual implementation of this will need to be done in debian-cd.git
where the boot menu for netinst images is definied.

For debian-edu it's probably enough to add a commandline parameter like this:
	preseed/early_command="anna-install debian-edu-profile-udeb"

For blends-tasks it's probably enough to add a commandline parameter like this:
	preseed/late_command="apt install -y blends-tasks"
(or probably better to turn blends-tasks into an udeb…)

To track and implement this, I will clone this bug and reassign the clone to
debian-cd (and then maybe file some more for some blends I care about).
Actually, no, I will file a new bug using only half of the text of this bug :)

I also plan to NMU blends-dev to set blends-tasks back to priority:optional,
probably on Thursday or Friday this week. (To give some time to discussion, 
but soon, to not let this slip for to long.) - and I'll make this change in
blends-dev.git right away.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Mon, 28 Nov 2016 10:09:56 +0100

Control: reassign -1 blends-tasks
Control: tags -1 moreinfo

Hi Holger,

thank you for your bug report to the "blends" package. I would, however
question a few things here and also ask for a little bit more information:

The "blends-tasks" package was created as a result of working on bug
#758116, titled "tasksel: Allow to select Blends selection during
installation - just 'DE', 'Web server', 'Mail server' is NOT enough".
This bug was created more than two years ago, and nowhere in the bug it
was questioned that the blends should be selectable during the
installation process. This, however, *requires* to have the information
about the blends available during installation, and this makes the
package that provides this information "important". Therefore, it is not
a policy violation, which in turn removes your argument to make this bug
"serious". It also does not "completely break the UI of the installer"
-- the selection is in no mean different from the desktop environment
selection. I would therefore propose to lower the severity of the bug.

Also, I would ask you to do an NMU until the discussion has settled
down. This would be an abuse of the NMU. NMUs are meant to deal with
unresponsive maintainers, and you did not show any evidence that the
blends maintainers are not responsive with respect to this problem.
Doing NMUs during a discussion is quite offending. I also don't see a
reason to hurry with implementing an unsettled decision: the blends
selection is there since almost 8 months now without any significant
change or discussion for ~6months. What makes the issue now so urgent
that you try to push this within four days? Why didn't you do this half
a year ago? We implemented the current solution at that time (and you
*knew* that we did) exactly to have some buffer for discussion about
critics. Why didn't you use that, but start now when it is quite late?

The next point is that you base your critics not on some experience with
the current installer but on an outdated, half-a-year-old screenshot.
Since then, several improvements were done, both in the appearance in
the installer, and in the selection of which blends are there. For the
first, see the discussion here:

https://lists.debian.org/debian-blends/2016/07/msg00027.html

We would also not include all blends there, but select them on an opt-in
base. So, if debian-edu is not useful to be installed that we, it shall
be removed. At the end, this will reduce the number of selectable blends
quite much.

I would therefore ask you to rebase your arguments on your experience
with the current implementation and not on something that is six months
old and not actual anymore.

Another point, concerning the argument of "confusing" users: As I said,
the blends-tasks package is in place now since eight months, with the
current implementation there since ~6 months. Since then there was no
single report that someone did not understand the options here -- no bug
report, nothing on the installer, blends, or devel mailing lists. I also
did an extensive search on the net, and the only thing I found is
mentioned in the discussion above and addressed by the changes made
after that. Since then, no single problem was reported, with more than
5000 installations according to popcon. This gives a good sign that the
addition of the blends to that menu does not confuse people, and I would
ask you to show a better empirical evidence that it does.

I will not discuss the arguments during the discussion in #758116 here
again -- there was a lengthy discussion about this, and the linked
postings were covered there as well. It makes no sense to repeat that
here again six months later.

Concerning your idea of having different install images, I am not
convinced that it is a good solution: First, it multiplies the whole
image creation process by the number of blends. If we have 10 official
architectures and (let's say) 5 blends to be included there, they would
then have to manage 60 images instead of 10, with all the requirements
that come out of this (installer manual, web page, updates, web space etc.).

But it also gives a wrong sign: Debian Pure Blends are by definition
integral part of Debian itself. But even now, this is hard to understand
for many people -- questions like "what is the difference between Debian
Astro and Debian" are quite common, even in front of a poster describing
exactly that. With having separate official images for all blends,
people would even be more confused. As an example, I would take the
Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
installation options -- people usually think that they have to
re-install the system if they want to switch from one flavour to the
other. Having similar experience with Debian would be bad for the
reputation of the Blends, and for Debian in general.

Best regards

Ole

Message #23 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tille@debian.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Mon, 28 Nov 2016 10:52:30 +0100

Hi,

On Mon, Nov 28, 2016 at 10:09:56AM +0100, Ole Streicher wrote:
> ...
> about the blends available during installation, and this makes the
> package that provides this information "important". Therefore, it is not
> a policy violation, which in turn removes your argument to make this bug
> "serious". It also does not "completely break the UI of the installer"
> -- the selection is in no mean different from the desktop environment
> selection. I would therefore propose to lower the severity of the bug.

+1

> <snipping lots of sensible text I'd fully subscribe.> 
>
> Concerning your idea of having different install images, I am not
> convinced that it is a good solution: First, it multiplies the whole
> image creation process by the number of blends. If we have 10 official
> architectures and (let's say) 5 blends to be included there, they would
> then have to manage 60 images instead of 10, with all the requirements
> that come out of this (installer manual, web page, updates, web space etc.).

I would say more drastical: Replacing multiple items in a menu by
multiple images to download will make the situation confusion which is
IMHO not yet.  It also fully ignores that people might want to install
DebiChem, Debian Med and Debian Science at the same time.

> But it also gives a wrong sign: Debian Pure Blends are by definition
> integral part of Debian itself. But even now, this is hard to understand
> for many people -- questions like "what is the difference between Debian
> Astro and Debian" are quite common, even in front of a poster describing
> exactly that. With having separate official images for all blends,
> people would even be more confused. As an example, I would take the
> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
> installation options -- people usually think that they have to
> re-install the system if they want to switch from one flavour to the
> other. Having similar experience with Debian would be bad for the
> reputation of the Blends, and for Debian in general.

I could not have said better.

Ole, thanks for your sensible response.

Kind regards

       Andreas.

PS: Just a warning.  Since I forgot to push my latest changes for blends
    0.6.96 the Git repository is a bit messy.  In case we would decide to
    revert Holger's changes some care might be needed.

-- 
http://fam-tille.de

Message #28 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Tue, 29 Nov 2016 17:04:31 +0100

Hi Holger,

On Sun, Nov 27, 2016 at 05:38:27PM +0100, Holger Levsen wrote:
> I also plan to NMU blends-dev to set blends-tasks back to priority:optional,
> probably on Thursday or Friday this week. (To give some time to discussion, 
> but soon, to not let this slip for to long.)

I wonder what your opinion about the two existing answers might be.  You
requested a discussion about your proposed patch but you did not took
part in the last 36 hours.

I hope you are fine and kind regards

      Andreas.

-- 
http://fam-tille.de

Message #33 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Tue, 29 Nov 2016 17:52:01 +0000

[Message part 1 (text/plain, inline)]

Hi Andreas (& Ole),

On Tue, Nov 29, 2016 at 05:04:31PM +0100, Andreas Tille wrote:
> I wonder what your opinion about the two existing answers might be.  You
> requested a discussion about your proposed patch but you did not took
> part in the last 36 hours.
> 
> I hope you are fine and kind regards

it's been almost 48h since I filed those bugs, of those I've spent >36h
traveling & sleeping & doing important "errands" and then I got busy preparing
a talk about jenkins.debian.net I'll give tomorrow noon, then I'll be
traveling & sleep again & some more important RL duties. I hope to reply on
Thursday… (and *maybe* I'll some time tomorrow…) 

I'm sorry about not being able to reply right now. Gotta catch another
train in 30 or 90min…

(I peeked into your replies very briefly and saw that I cannot reply quickly…)


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #38 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Tue, 29 Nov 2016 19:30:50 +0100

On Tue, Nov 29, 2016 at 05:52:01PM +0000, Holger Levsen wrote:
> I'm sorry about not being able to reply right now. Gotta catch another
> train in 30 or 90min…
> 
> (I peeked into your replies very briefly and saw that I cannot reply quickly…)

OK, take your time, have a nice travel - but please delay your planed
NMU until we can *really* discuss the issue.

Kind regards

     Andreas.

-- 
http://fam-tille.de

Message #43 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Samuel Thibault <sthibault@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org, debian-cd@packages.debian.org, debian-boot@lists.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Fri, 2 Dec 2016 08:24:04 +0100

Hello,

Holger Levsen, on Sun 27 Nov 2016 17:38:27 +0100, wrote:
> So how to fix this *and* allow Debian blends be installed easily from
> official Debian media?

[...]

> The idea is, that these images have the *same features* (and packages), the
> differences are just which the preselected default in the boot menu.
[...]
> This has several benefits:
> - it's possible to tell people "download $this iso to install $this type of
>   Debian"

> For blends-tasks it's probably enough to add a commandline parameter like this:
> 	preseed/late_command="apt install -y blends-tasks"
> (or probably better to turn blends-tasks into an udeb…)

This makes me think about a recurring issue: being able to easily
personalize an ISO image.

It's useful to have an ISO image that "just install this and that on the
whole disk without asking anything" without having to setup PXE.

It's useful to have an ISO image that just directly uses the native
language of the target users.

We need it for accessibility for the cases where a braille device
can not be automatically detected for instance, some parameter must
be manually set, and that can't be done in an accessible way in the
bootloader.


Of course, that's called preseeding, one just has to stuff a preseed.cfg
file on a key.  But one also have to put magic stuff on the kernel
command line to get it loaded, etc.  It's really far from convenient
(and doesn't fix the accessibility case).



I was thinking that we could reserve some room on the ISO image itself
to contain this, so that it can be easily patched over.  Something
like a dumb preseeding file full of comments, to have enough room for
personalization.  The idea would be that the official Debian images have
this file with a well-known content.  Personalization tools can then
just change the content, without having to rebuild the ISO image.  Such
personalized ISO image then fails any checksum verification of course,
but one can revert the personalization by putting back the well-known
content, and thus be able to verify the checksum.


With such a setup, the various blend images could be simply
personalizations of the officiel CD image.  The personalization step
could be done by the blend teams and put for download, or it could even
somehow be done on the fly at download time.



As a side note:

> For illustration, these are some netinstall image _flavors_/_spins_ I have in mind:
> 
> 	debian-classic / textmode d-i
> 	debian-graphical installer
> 	blends selection (graphical)
> 	debian-edu blend (graphical)
> 	debian-parl blend (graphical)


> 	debian-speakup (textmode d-i with speech enabled by default)

This one does not make sense: using speech is completely orthogonal to
everything else. That's why it's a boot entry on all images.

Samuel

Message #48 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: Samuel Thibault <sthibault@debian.org>, 846002@bugs.debian.org, Holger Levsen <holger@layer-acht.org>, debian-cd@packages.debian.org, debian-boot@lists.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Fri, 02 Dec 2016 10:11:15 +0100

[Samuel Thibault]
> This makes me think about a recurring issue: being able to easily
> personalize an ISO image.
>
> It's useful to have an ISO image that "just install this and that on the
> whole disk without asking anything" without having to setup PXE.

This would be most easy to implement by teaching the preseed udeb to
look for a preseed file in the same partition as the hwdetect udeb is
looking for firmware.  If this partition exist on the ISO/USB stick,
preseed could look for a well known file name (say preseed-default.cfg),
and load it if it exist.  Should be less than 50 lines of changes to the
preseed udeb.

-- 
Happy hacking
Petter Reinholdtsen

Message #53 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: 846002@bugs.debian.org

Subject: Lowering severity

Date: Mon, 5 Dec 2016 09:58:03 +0100

Control: Severity -1 normal


Since no objections against my proposal were expressed for a week, I am
lowering the severity.

Since there is no update of the bug report with more recent experiences,
I will to close it as of version 0.6.94 within a few days.


Best regards


Ole

Message #60 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: Lowering severity

Date: Mon, 5 Dec 2016 12:46:22 +0000

[Message part 1 (text/plain, inline)]

On Mon, Dec 05, 2016 at 09:58:03AM +0100, Ole Streicher wrote:
> Control: Severity -1 normal
> 
> Since no objections against my proposal were expressed for a week, I am
> lowering the severity.
> 
> Since there is no update of the bug report with more recent experiences,
> I will to close it as of version 0.6.94 within a few days.

I'm sorry that I failed to respond yet. 

Still, this doesnt make a policy violation a non-policy violation.
(Priority: important is *wrong* for this package.)

You are forcing the installation of blends-tasks on every Debian
system. This is *not ok*.

I will try to reply ASAP, but… I might fail and just reassign to
tech-ctte. (I also find it very hard to find time for this as you failed
to understand the problem with the current implementation from the
beginning, so I'm doubtful whether trying again (for like the 4th or 5th
time will change anything.)

And regarding the blends task selection itself, it has been discussed
in d-i to just blacklist blends-tasks or to remove the feature which
allows to drop tasks into tasksel like this. I'm really not the only
one thinking that this blends selection menu in the default installation
is a no-go as it is.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: control@bugs.debian.org, 846002@bugs.debian.org

Cc: debian-ctte@lists.debian.org

Subject: blends-dev must not be "priority: important" - was Re: Bug#846002: Lowering severity

Date: Mon, 5 Dec 2016 13:02:07 +0000

[Message part 1 (text/plain, inline)]

reassign 846002 tech-ctte
thanks

On Mon, Dec 05, 2016 at 09:58:03AM +0100, Ole Streicher wrote:
> Control: Severity -1 normal

src:blends 0.6.93 uploaded on 09 Apr 2016 introduced a new binary
package, blends-dev, with "priority: important", causing it to be
installed on *all* systems by debootstrap by default.

https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities is
quite clear what important packages are, and IMO blends-dev clearly
doesnt qualify as "noone expects it."

IMO blends-tasks rather should be of priority: optional.

Dear tech-ctte, please clarify. I don't have the time nor energy for
bts-ping-pong, but Ole said he is going to close this bug soon (in
addition to setting the severity to "normal") and closing this bug
without changing the priority would just be wrong, IMO.

Thanks. (And sorry for my lack of patience here.)

(I'm also not sure who has the final say on definining priorities, the
ftpmasters maybe? Feel free to swiftly re-assign there.)


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #74 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: Lowering severity

Date: Mon, 5 Dec 2016 14:34:56 +0100

Hi Holger,

On 05.12.2016 13:46, Holger Levsen wrote:
> I'm sorry that I failed to respond yet. 

I am quite angry about this: You basically opened this bug by stating
that you will do an NMU within 4-5 days, but you already knew that you
would not have time to discuss the bug before you planned this to happen.

This puts quite some pressure to us to respond within a reasonable time
-- and then you (who clearly expressed how important you think this is)
hide yourself and fail to respond.

This all happens after half a year of silence from you, where we could
have discussed this and find alternatives without too much pressure.

And you even didn't check the current status before filing the bug.

Sorry, but this doesn't sound like a sensible behavior to get a good
solution.

> Still, this doesnt make a policy violation a non-policy violation.
> (Priority: important is *wrong* for this package.)

It is as wrong as for tasksel-data: if we want to have blends selection
in the installer, then this information needs to be available there.

Lowering the bug severity was done since I proposed so and did not get a
veto reply (covering my arguments) from you within a week.

> You are forcing the installation of blends-tasks on every Debian
> system. This is *not ok*.

In principle, the whole package could be integrated into tasksel-data.
However, this makes the work more complicated for the (already
overloaded) tasksel maintainers, since they also would have to deal with
the integration of the individual blends. The current solution keeps the
maintenance of the blends tasks in the installer in the responsibility
of the blends team.

I don't see why this solution is worse than to have it combined in a
single package (or file) -- it is even better since it moves
responsibilities away from an already overloaded team.

> I will try to reply ASAP, but… I might fail and just reassign to
> tech-ctte. (I also find it very hard to find time for this as you failed
> to understand the problem with the current implementation from the
> beginning, so I'm doubtful whether trying again (for like the 4th or 5th
> time will change anything.)

I brought some arguments. It would be nice if you could respond to them.

Since you even didn't check the current state, it is hard to discuss
here. As I explained, your arguments are already handled with version
0.6.95.

I would prefer to have the arguments discussed first instead of just
re-assigning to tech-ctte (which you did while I writing this reply, and
before you even started to handle Andreas' and my arguments).

Best regards

Ole

Message #79 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Ole Streicher <olebole@debian.org>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: Lowering severity

Date: Mon, 5 Dec 2016 13:43:18 +0000

[Message part 1 (text/plain, inline)]

On Mon, Dec 05, 2016 at 02:34:56PM +0100, Ole Streicher wrote:
> I am quite angry about this: You basically opened this bug by stating
> that you will do an NMU within 4-5 days, but you already knew that you
> would not have time to discuss the bug before you planned this to happen.

I didnt knew that. Once again I was naive.
 

-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #84 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org, Holger Levsen <holger@layer-acht.org>

Subject: Re: Bug#846002: Lowering severity

Date: Mon, 5 Dec 2016 09:43:18 -0600

Control: reassign -1 src:blends

On Mon, 05 Dec 2016, Ole Streicher wrote:
> On 05.12.2016 13:46, Holger Levsen wrote:
> > I'm sorry that I failed to respond yet. 
> 
> I would prefer to have the arguments discussed first instead of just
> re-assigning to tech-ctte (which you did while I writing this reply, and
> before you even started to handle Andreas' and my arguments).

On Mon, 05 Dec 2016, Holger Levsen wrote:
> I didnt knew that. Once again I was naive.

In light of this, I'm going to unilaterally reassign this back to
Source: blends; if either of you disagree (or anyone else on the CTTE
disagrees) and still want the CTTE to resolve this (slowly), feel free
to reassign it back.

-- 
Don Armstrong                      https://www.donarmstrong.com

"I always tend to assume there's an infinite amount of money out
there." "There might as well be, [...] but most of it gets spent on
pornography, sugar water, and bombs. There is only so much that can be
scraped together for particle accelerators."
 -- Neal Stephenson _Anathem_ p262

Message #91 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: debian-ctte@lists.debian.org

Cc: 846002@bugs.debian.org

Subject: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Mon, 5 Dec 2016 20:07:19 +0000

[Message part 1 (text/plain, inline)]

control: reassign -1 tech-ctte
control: retitle -1 blends-tasks must not be priority:important
thanks

On Mon, Dec 05, 2016 at 09:43:18AM -0600, Don Armstrong wrote:
> if either of you disagree (or anyone else on the CTTE
> disagrees) and still want the CTTE to resolve this (slowly), feel free
> to reassign it back.

Noted, thanks.

And yes, I still think it's really really wrong to have blends-tasks have
"priority: important" which makes it getting installed by each and every
debootstrap run by default.

https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

(And I'm really in no good position/mood/whatever to argue this any
further. To me this issue is very very clear and I'm sometimes not good
argueing issues which I think are very very clear.)

Thus, the reassign.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #100 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: Holger Levsen <holger@layer-acht.org>

Cc: 846002@bugs.debian.org

Subject: Re: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Mon, 5 Dec 2016 15:17:41 -0600

Control: clone -1 -2
Control: reassign -2 src:blends
Control: block -2 by -1

On Mon, 05 Dec 2016, Holger Levsen wrote:
> And yes, I still think it's really really wrong to have blends-tasks have
> "priority: important" which makes it getting installed by each and every
> debootstrap run by default.

OK.

I'm cloning the original bug, reassigning it, and blocking it by the
CTTE bug (which will maintain its original number for further
discussion.)

Of the technical solutions existing currently, it seems that either we:

1) require the demotion of blends-tasks from 'important' to
'optional/extra'

2) don't require the demotion of blends-tasks

I personally thing that one of the better solutions outlined in
https://bugs.debian.org/758116 would be better, but until they exist, we
cannot decide about them.


-- 
Don Armstrong                      https://www.donarmstrong.com

Democracy is more dangerous than fire. Fire can't vote itself immune
to water.
 -- Michael Z. Williamson

Message #109 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Don Armstrong <don@debian.org>

Cc: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Mon, 05 Dec 2016 18:07:49 -0500

So, what impact does having blends-tasks have besides wasting disk
space.
It adds tasks to the installer menu.  Are those tasks we want on all
system installs or not?
If this is purely about disk space, I think it's less of an issue than
if it provides a bad user experience.

Message #114 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Mon, 5 Dec 2016 17:29:19 -0600

On Mon, 05 Dec 2016, Sam Hartman wrote:
> So, what impact does having blends-tasks have besides wasting disk
> space.

It results in multiple extra tasks listed in the task selection screen
without describing the tasks or putting them into a submenu or similar.

[The screen shot Holger linked to is a screen shot of the installer at
the tasksel screen showing an entry for "Debian Blends" followed by a
series of entries which start with leading periods followed by entries
like "HamRadio" and "DebiChem".]

-- 
Don Armstrong                      https://www.donarmstrong.com

"I always tend to assume there's an infinite amount of money out
there." "There might as well be, [...] but most of it gets spent on
pornography, sugar water, and bombs. There is only so much that can be
scraped together for particle accelerators."
 -- Neal Stephenson _Anathem_ p262

Message #119 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Don Armstrong <don@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 09:00:39 +0100

Hi all,

On 06.12.2016 00:29, Don Armstrong wrote:
> [The screen shot Holger linked to is a screen shot of the installer at
> the tasksel screen showing an entry for "Debian Blends" followed by a
> series of entries which start with leading periods followed by entries
> like "HamRadio" and "DebiChem".]

This screenshot is outdated since several months. Currently, the wording
is different, and the number of included blends has shrunken a lot.

Best regards

Ole

Message #124 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tille@debian.org>

To: 846002@bugs.debian.org

Cc: debian-ctte@lists.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 09:45:27 +0100

Hi Holger,

On Mon, Dec 05, 2016 at 08:07:19PM +0000, Holger Levsen wrote:
> control: reassign -1 tech-ctte
> control: retitle -1 blends-tasks must not be priority:important
> thanks
> 
> On Mon, Dec 05, 2016 at 09:43:18AM -0600, Don Armstrong wrote:
> > if either of you disagree (or anyone else on the CTTE
> > disagrees) and still want the CTTE to resolve this (slowly), feel free
> > to reassign it back.
> 
> Noted, thanks.
> 
> And yes, I still think it's really really wrong to have blends-tasks have
> "priority: important" which makes it getting installed by each and every
> debootstrap run by default.
> 
> https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
> 
> (And I'm really in no good position/mood/whatever to argue this any
> further.

I think it becomes pretty obvious that you are not in the mood to argue
about the topic you brought up based on outdated data.  You also did not
responded to Ole's argument[1] that also tasksel-data has the same
"conflict" with policy you are blaming blends-tasks.

> To me this issue is very very clear and I'm sometimes not good
> argueing issues which I think are very very clear.)

The fact that it is very clear (I do not see in how far repeating 'very'
makes things even clearer) to you is not really convincing.  My summary
of the issue is:

  * Holger does not like the look of presenting tasks as they
    where half a year ago.
  * The look was changed in the mean time since other also were
    not happy and Ole has shrinked the length to an extend that
    was considered sensible by those members of the Blends team
    who cared.
  * The Blends team is considering it important to present the
    Blends as options to the users to pick from at install time
    (as they pick from the set of tasks in tasksel-data).  The
    comparison is pretty valid since it makes sense to pick from
    more than one Blend and the solution suggested by Holger to
    provide separate installation media will not solve this.
  * Valid reasons why blends-tasks are not included into
    tasksel-data were given by Ole[1].
  * The conflict with policy seems artificial to me and I have the
    bad feeling Holger intends to hire people advocating his point
    instead of answering the arguments given in the bug report.  I
    admit that's the first bug I'm involved that is brought up in
    the CTTE and thus I might have a wrong impression but my gut
    feeling says that its wrong to bother this instance with the
    issue in the current state.

Kind regards

        Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002#74

-- 
http://fam-tille.de

Message #129 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Andreas Tille <tille@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 09:04:02 +0000

[Message part 1 (text/plain, inline)]

On Tue, Dec 06, 2016 at 09:45:27AM +0100, Andreas Tille wrote:
>   * Holger does not like the look of presenting tasks as they
>     where half a year ago.

wrong.

>   * The conflict with policy seems artificial to me 

wrong.

> and I have the
>     bad feeling Holger intends to hire people advocating his point
>     instead of answering the arguments given in the bug report.

wow.

I'll have to let *this* sink.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #134 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org, Don Armstrong <don@debian.org>

Cc: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 10:18:23 +0100

[Message part 1 (text/plain, inline)]

Sam Hartman <hartmans@debian.org> writes:

> So, what impact does having blends-tasks have besides wasting disk
> space.
> It adds tasks to the installer menu.  Are those tasks we want on all
> system installs or not?
> If this is purely about disk space, I think it's less of an issue than
> if it provides a bad user experience.

It makes the "what do you want to install?" menu slightly worse by
introducing some more befuddling options to it.  It was already dire
though.

Before this you'd be confronted with (I'll type the text version, so
people don't need to follow links to screenshots -- please forgive
typos):

   [x]  Debian Desktop Environment
   [ ]  ... Gnome
   [ ]  ... Xfce
   [ ]  ... KDE
   [ ]  ... Cinnamon
   [ ]  ... MATE
   [ ]  ... LXDE
   [ ]  ... LXQt
   [ ]  web server
   [x]  print server
   [ ]  SSH server
   [x]  standard system utilities

So, this was already a disaster area:

  What does selecting Debian Desktop Environment, but none of the
  desktops do (it gives you Gnome, but there's no real hint here)

  How about if you deselect Debian Desktop Environment, and select Gnome
  and KDE?  (the desktop tasks all depend on task-desktop, so you get it
  anyway AFAIK, but that's not the impression given).

  What is a print server? (CUPS) web server? (apache2)

  What do you get if you install without the standard system utilities,
  does that still hold if you install a full desktop?

  Are we really expecting the people that we feel we must protect from
  package names by hiding the fact that we're talking about CUPS and
  Apache to know what LXQt is?

After adding the blends, that becomes this (having just used the daily
mini.iso downloaded this morning):

   [x]  Debian Desktop Environment
   [ ]  ... Gnome
   [ ]  ... Xfce
   [ ]  ... KDE
   [ ]  ... Cinnamon
   [ ]  ... MATE
   [ ]  ... LXDE
   [ ]  ... LXQt
   [ ]  web server
   [x]  print server
   [ ]  SSH server
   [x]  standard system utilities
   [ ]  Special tasks
   [ ]  ... astronomy (Debian Astro)
   [ ]  ... games and fun (Debian Games)
   [ ]  ... life sciences and medicine (Debian Med)

so that then prompts one to wonder:

  what the hell is "Special tasks" and what will I get if I select it?

  Do I need to select that to get Debian Med, say?
    (no, it's just an empty header AFAIK)

it also buries the 'standard system utilities' item in the middle of
the list, where it makes even less sense than it did at the end.

So, I'd say that the whole thing was a car-crash anyway, and this just
dropped a cigarette in the spilling petrol.

The real problem is that there's not been the effort available in the
d-i team to come up with some better way of presenting the question.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #139 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org, Sam Hartman <hartmans@debian.org>, Don Armstrong <don@debian.org>

Cc: Holger Levsen <holger@layer-acht.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important

Date: Tue, 6 Dec 2016 10:34:23 +0100

On 06.12.2016 10:18, Philip Hands wrote:
> it also buries the 'standard system utilities' item in the middle of
> the list, where it makes even less sense than it did at the end.

The positions of the items can be changed by assigning a "Relevance"
(one digit) to them. So, if the "Standard" task should be on top (what I
would prefer), it should get a high relevance; if it should be at the
end, it should get a low relevance. Currently, there is no relevance
specified for the "Standard" task, therefore it defaults to 5.

The blends tasks have "Relevance: 8", since I intended to have the
blends at the end (which is the right place for special tasks, IMO).
There is room for one relevance below, and if this is not enough, we
could rise the blends relevance: I just thought that there is probably
more need to sort things before than after the "Special tasks".

Best regards

Ole

Message #144 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Philip Hands <phil@hands.com>

Cc: Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org, Don Armstrong <don@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 09:37:19 +0000

[Message part 1 (text/plain, inline)]

Thanks, Phil.

On Tue, Dec 06, 2016 at 10:18:23AM +0100, Philip Hands wrote:
> It makes the "what do you want to install?" menu slightly worse by
> introducing some more befuddling options to it.  It was already dire
> though.

exactly.
 
> Before this…
[...] 
> So, this was already a disaster area:
> 
>   What does selecting Debian Desktop Environment, but none of the
>   desktops do (it gives you Gnome, but there's no real hint here)
> 
>   How about if you deselect Debian Desktop Environment, and select Gnome
>   and KDE?  (the desktop tasks all depend on task-desktop, so you get it
>   anyway AFAIK, but that's not the impression given).
> 
>   What is a print server? (CUPS) web server? (apache2)
> 
>   What do you get if you install without the standard system utilities,
>   does that still hold if you install a full desktop?
> 
>   Are we really expecting the people that we feel we must protect from
>   package names by hiding the fact that we're talking about CUPS and
>   Apache to know what LXQt is?

exactly.

> After adding the blends, that becomes this (having just used the daily
> mini.iso downloaded this morning):
> 
>    [x]  Debian Desktop Environment
>    [ ]  ... Gnome
>    [ ]  ... Xfce
>    [ ]  ... KDE
>    [ ]  ... Cinnamon
>    [ ]  ... MATE
>    [ ]  ... LXDE
>    [ ]  ... LXQt
>    [ ]  web server
>    [x]  print server
>    [ ]  SSH server
>    [x]  standard system utilities
>    [ ]  Special tasks
>    [ ]  ... astronomy (Debian Astro)
>    [ ]  ... games and fun (Debian Games)
>    [ ]  ... life sciences and medicine (Debian Med)

indeed, this is what it looks today. Just verified myself too.

And this *is* still pretty confusing, though admitly better than it was
half a year ago. 

> so that then prompts one to wonder:
> 
>   what the hell is "Special tasks" and what will I get if I select it?

exactly

>   Do I need to select that to get Debian Med, say?
>     (no, it's just an empty header AFAIK)
> 
> it also buries the 'standard system utilities' item in the middle of
> the list, where it makes even less sense than it did at the end.

and it will only get worse, if we would keep it this way… We have *many* more
blends in Debian… Debian Parl, Debian Junor, Debian Edu come to my mind
immediatly.

why list some and not some others? 

and really, the list is too long already. please read 

	https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#320
	https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#340

> So, I'd say that the whole thing was a car-crash anyway, and this just
> dropped a cigarette in the spilling petrol.

*hahaha*

> The real problem is that there's not been the effort available in the
> d-i team to come up with some better way of presenting the question.

yes. 

and that this bug should not be about this tasksel menu but *about this
was implemented*, which is by forcing an unneeded package on each and
every Debian system under the sun. (priority: important…)

- while this could have been implemented using udebs, thus not affecting
installed systems! (debian-edu-profile-udeb is an existing example how
to do that.)

But really, there are two issues: how the menu should look like and
whether we want "random" packages to be allowed to declare themselves
priority: important and to be installed everywhere. I failed to make
this clear initially, though I have tried by filing #846003 (and
005+006) as well.


-- 
cheers,
	Holger, who will try his very best to shut up on this issue now.
		I have other fish to fry, and as I'm used to do "apt
		install screen vim less git" on any new system, I will
		get used to type "apt remove blends-tasks" as well.
		It's just stupid and bad design.

[signature.asc (application/pgp-signature, inline)]

Message #149 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org, Philip Hands <phil@hands.com>

Cc: Sam Hartman <hartmans@debian.org>, Don Armstrong <don@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 11:29:10 +0100

On 06.12.2016 10:37, Holger Levsen wrote:
> And this *is* still pretty confusing, though admitly better than it was
> half a year ago. 

The current implementation has a popcon of >5000, without a single
complaint or confusion documented in the web within the last six months.
This is at least *some* empirical evidence that it is not "pretty
confusing", and again I would ask you to show any better empirical data
here to support your own point.

> and it will only get worse, if we would keep it this way… We have *many* more
> blends in Debian… Debian Parl, Debian Junor, Debian Edu come to my mind
> immediatly.
> why list some and not some others? 


The "single checkbox" is not usable for all blends, since it requires a
"one size fits all" solution. For Debian Edu, you already stated
yourself that it is useless. Debian Junior and Debian Parl didn't opt
in. I therefore don't see a danger that the list will grow endlessly
before Stretch.

> and that this bug should not be about this tasksel menu but *about this
> was implemented*, which is by forcing an unneeded package on each and
> every Debian system under the sun. (priority: important…)

I already answered to this: there is no technical reason to have the
blends task in an individual package; technically it could also be put
into tasksel-data itself.

However, this would require action from the tasksel team every time
something changes in the blends task. d-i is already overloaded, and it
will not help if we put another responsibility on top of that. So, it is
a good solution to separate the responsibility of the "Special tasks"
item to the blends team.

Compared to an integrated (into tasksel-data) solution, the size impact
is minimal: mainly the overhead of having an additional package there.
If we care about this overhead, the problem would apply to tasksel-data
as well.

Best regards

Ole

Message #154 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Cc: Sam Hartman <hartmans@debian.org>, Don Armstrong <don@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 12:02:05 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> writes:

> On 06.12.2016 10:37, Holger Levsen wrote:
>> And this *is* still pretty confusing, though admitly better than it was
>> half a year ago. 
>
> The current implementation has a popcon of >5000, without a single
> complaint or confusion documented in the web within the last six months.
> This is at least *some* empirical evidence that it is not "pretty
> confusing", and again I would ask you to show any better empirical data
> here to support your own point.

You seem to be mixing up two things here.

Holger was saying that the menu is confusing (as am I).

You're saying that because 5000 people seem to have ended up with this
package on their systems, they were not confused.

Looking at the graph for debian-astro, is seems to follow a similar
curve, so perhaps these are the people that are installing the
blends-tasks (BTW is there an easy way to check which packages are
installed together via popcon?)

There is no need for them to tick the 'Special tasks' menu item in order
to install any of the the blends, so to some tiny extent they were
confused when they did that, were they not?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #159 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Cc: Sam Hartman <hartmans@debian.org>, Don Armstrong <don@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 12:32:50 +0100

On 06.12.2016 12:02, Philip Hands wrote:
> Ole Streicher <olebole@debian.org> writes:
> 
>> On 06.12.2016 10:37, Holger Levsen wrote:
>>> And this *is* still pretty confusing, though admitly better than it was
>>> half a year ago. 
>>
>> The current implementation has a popcon of >5000, without a single
>> complaint or confusion documented in the web within the last six months.
>> This is at least *some* empirical evidence that it is not "pretty
>> confusing", and again I would ask you to show any better empirical data
>> here to support your own point.
> 
> You seem to be mixing up two things here.
> 
> Holger was saying that the menu is confusing (as am I).
> 
> You're saying that because 5000 people seem to have ended up with this
> package on their systems, they were not confused.

I am saying that from these 5000 people nobody asked for help or
complained in the web, except for the initial wording. This initial
documented confusion shows that we actually *get* a response here (and
the search is not just useless).

> Looking at the graph for debian-astro, is seems to follow a similar
> curve, so perhaps these are the people that are installing the
> blends-tasks (BTW is there an easy way to check which packages are
> installed together via popcon?)

The relevant package from debian-astro (which is going to be installed
with by tasksel) is "astro-all". It has a popcon of 148, so most of the
people installing blends-tasks (5400) then do not install debian-astro.

The curve for both is similar, since both were introduced together:
astro-all was specifically created to do the actual installation of
Debian-Astro via the installer tasksel.

> There is no need for them to tick the 'Special tasks' menu item in order
> to install any of the the blends, so to some tiny extent they were
> confused when they did that, were they not?

I also find the structure here not optimal; this is however given by the
limitation that tasksel uses debconf, which has only limited
possibilities. The checkbox in "Special tasks" is confusing for sure.

However, this does not add confusion: the same problem is already there
(and was so in Jessie) with the "Desktop environment", so people need to
get used to it anyway -- we don't solve this by deciding the current issue.

What the empirical search however shows that the blends-tasks didn't add
additional confusion here.

Best regards

Ole

Message #164 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 12:58:22 +0100

[Message part 1 (text/plain, inline)]

With my Debian Printing Team member hat:

Le mardi, 6 décembre 2016, 10.18:23 h CET Philip Hands a écrit :
>   What is a print server? (CUPS) web server? (apache2)

The "print server" entry in tasksel should be rethought, as it nowadays only 
depends on CUPS, and recommends various helper drivers & co. If one really 
wants to setup a shared print server, they would install CUPS on a pristine 
Debian and configure CUPS from there on. If CUPS is "only" meant to be used as 
local print server, it should really be a recommends of the desktop tools 
caring about printing.

I don't really see the point anymore about having this entry in the d-i tasks 
selection; and would suggest to remove it entirely, and (eventually) add an 
entry in the Release Notes saying "if you want a print-server, install CUPS".

Btw, there's https://bugs.debian.org/824645 for which I put up a cleanup 
patch, but I can't push it. :/

    OdyX

[signature.asc (application/pgp-signature, inline)]

Message #169 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: 846002@bugs.debian.org

Subject: Re: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 15:06:09 +0100

Hi,

IMHO the whole discussion is mixing up two things:

  1. If it is correct that blends-tasks has priority 'important'
     or not.

  2. If the user visible presentation of Blends selection is
     good or not.


Regarding 1. we have the following quotes:

From: Holger Levsen <holger@layer-acht.org>
Date: Mon, 5 Dec 2016 12:46:22 +0000

> You are forcing the installation of blends-tasks on every Debian
> system. This is *not ok*.


From: Ole Streicher <olebole@debian.org>
Date: Mon, 5 Dec 2016 14:34:56 +0100

> It is as wrong as for tasksel-data: if we want to have blends selection
> in the installer, then this information needs to be available there.


So this boils down to the decision whether for Strecht Blends will be
considered as important as at the time when tasks were invented and
tasksel-data was allowed to be 'important' despite the fact that it is
not really a "bare minimum of commonly-expected and necessary tools".



Regarding 2. Don has correctly pointed to the *implementation* of the
selection.  I think for the user experience this is the main important
point since the user will probably not care in what package the data
that are needed to present the menu are bundled.


Kind regards

      Andreas.

-- 
http://fam-tille.de

Message #174 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 15:16:34 +0100

[ Sorry for breaking the thread but despite I've subscribed the bug
  I need to read it in the browser since I do not receive the mails :-(]

Hi Philip,

On Tue, 06 Dec 2016 12:02:05 +0100 Philip Hands wrote:
> There is no need for them to tick the 'Special tasks' menu item in order
> to install any of the the blends, so to some tiny extent they were
> confused when they did that, were they not?

Just a data point:  Despite the fact that since 2002 med-* metapackages
exist and I'm talking at various events about it all my talks are
featuring the same question from the auditorium:  "How can I install
Debian Med".  We now have some implementation which is not nice in terms
of a usable user menu (I'd be happy about any suggestion how to enhance
this).  We have an implementation for something that from my personal
point of view is urgent for every Blend that is considered releasable by
its team members (and some are not thus the shortened list).

The work of Blends teams is targeting to make Debian the best
distribution in certain work fields and I'm positively convinced that we
have approached this in some fields.  However, the step to tell users
about this success on a technical level (and who is reading the docs
:-P) is the last missing bit which we intend to do by adding it to the
installer.

Kind regards

       Andreas.

-- 
http://fam-tille.de

Message #179 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org, Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org, Don Armstrong <don@debian.org>

Cc: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 08:10:37 -0700

[Message part 1 (text/plain, inline)]

Philip Hands <phil@hands.com> writes:

> So, I'd say that the whole thing was a car-crash anyway, and this just
> dropped a cigarette in the spilling petrol.

Yeah.  I'm not immediately sure to suggest as a way to do things
differently, and this may not seem immediately helpful... but about the
first piece of advice I give most new-to-Debian users I'm helping out
personally is to just ignore the concept of tasks and pick software they
actually want on their system.

Bdale

[signature.asc (application/pgp-signature, inline)]

Message #184 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Andreas Tille <andreas@an3as.eu>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 10:28:46 -0500

For what it's worth, I think the policy question here is not a
significant one.

Holger is right that we should either fix policy or fix both
(tasksel-data and blends-tasks).
I think that is a bug that should get hashed out.  I don't think it is
all that timely, and I don't think it matters much how we handle things.
It seems clear that if we want the data available for tasksel, then when
tasksel runs, both tasksel-data and blends-tasks need to be installed.
How to align policy and implementation is something we should eventually
figure out.

I think the far more important question is whether the presentation of
blends is what our users need.

Message #189 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 17:04:57 +0100

]] Ole Streicher 

> On 06.12.2016 10:37, Holger Levsen wrote:
> > And this *is* still pretty confusing, though admitly better than it was
> > half a year ago. 
> 
> The current implementation has a popcon of >5000, without a single
> complaint or confusion documented in the web within the last six months.
> This is at least *some* empirical evidence that it is not "pretty
> confusing", and again I would ask you to show any better empirical data
> here to support your own point.

It's confusing enough that when I've had engineers from a provider
install Debian for me, I have ended up with a desktop rather than server
installation.  Should I have filed a bug about it?  Maybe.

I think it would be better if we moved most of tasksel out of the
installer entirely and had an app store of some sort where applications
and blends could all be better presented with screenshots and
all. That's obviously out of scope for stretch, and it's not something
that the CTTE is going to do (if nothing else because you'd be far into
«detailed design work» territory).  This would leave the installer with
a «Do you want a graphical UI and/or sshd?» as a question/questions,
rather than a list of tasks, some which make less sense today (CUPS) and
some which are cryptic (what's the difference between LXDE and
LXQt?).

Historically, for Debian-Edu, there were regular and thin client server
profiles, thin client installations and so on which are a bit more than
«install this set of packages», which is (AIUI) what most blends are
today, so integration into the installer was pretty important.  I'm not
sure pure package set variants should live as part of the installer at
all. They're really easy to install later, and by adding extra steps to
the installer, we're making Debian harder to install for everybody, not
just those interested in the blends.

Again, I don't know how feasible it is to end up with a better design
for stretch, but I don't think the current design is particularly
scalable and should be replaced for buster.

(I realise this doesn't answer the question in the bug report, but those
are some related thoughts.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #194 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 16:19:36 +0000

On Tue, Dec 06, 2016 at 05:04:57PM +0100, Tollef Fog Heen wrote:
>]] Ole Streicher 
>
>> On 06.12.2016 10:37, Holger Levsen wrote:
>> > And this *is* still pretty confusing, though admitly better than it was
>> > half a year ago. 
>> 
>> The current implementation has a popcon of >5000, without a single
>> complaint or confusion documented in the web within the last six months.
>> This is at least *some* empirical evidence that it is not "pretty
>> confusing", and again I would ask you to show any better empirical data
>> here to support your own point.
>
>It's confusing enough that when I've had engineers from a provider
>install Debian for me, I have ended up with a desktop rather than server
>installation.  Should I have filed a bug about it?  Maybe.
>
>I think it would be better if we moved most of tasksel out of the
>installer entirely and had an app store of some sort where applications
>and blends could all be better presented with screenshots and
>all. That's obviously out of scope for stretch, and it's not something
>that the CTTE is going to do (if nothing else because you'd be far into
>«detailed design work» territory).  This would leave the installer with
>a «Do you want a graphical UI and/or sshd?» as a question/questions,
>rather than a list of tasks, some which make less sense today (CUPS) and
>some which are cryptic (what's the difference between LXDE and
>LXQt?).

I'm not so sure. I think that what we could really do with is a more
intelligent UI here to allow for multi-level choices:

 + Desktop UI?
   + Gnome
   + KDE
   ...
 + Server tasks
   + SSH server
   + File server
   + Web server
   ...
 + Debian Pure Blends
   + Astro
     + Astro option 1
     + Astro option 2
   + Debian-Edu
   ...

etc. I've pondered about how to do achieve that with the existing
debconf code, but not got very far yet. Including more descriptive
text and maybe even screen shots with each would be very helpful.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer

Message #199 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 17:41:49 +0100

Hi Sam,

On Tue, Dec 06, 2016 at 10:28:46AM -0500, Sam Hartman wrote:
> For what it's worth, I think the policy question here is not a
> significant one.
> 
> Holger is right that we should either fix policy or fix both
> (tasksel-data and blends-tasks).
> I think that is a bug that should get hashed out.  I don't think it is
> all that timely, and I don't think it matters much how we handle things.
> It seems clear that if we want the data available for tasksel, then when
> tasksel runs, both tasksel-data and blends-tasks need to be installed.
> How to align policy and implementation is something we should eventually
> figure out.

Thanks for confirming that.  So in this bug we are rather discussing the
second point of my remark[1].
 
> I think the far more important question is whether the presentation of
> blends is what our users need.

Yes.  I think I made my point clear about this and you also know that
I'm quite biased here - so no additional comments. :-)

Thanks to all CTTE members for their work

     Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002#169

-- 
http://fam-tille.de

Message #204 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 6 Dec 2016 18:12:50 +0100

Hi Bdale,

On Tue, 06 Dec 2016 08:10:37 -0700 Bdale Garbee wrote:
> the first piece of advice I give most new-to-Debian users I'm helping out
> personally is to just ignore the concept of tasks and pick software they
> actually want on their system.

To solve this very problem we actually invented the tasks in Blends:  It
simply helps picking the software users want on their system without
browsing the n (insert number of binary packages here) descriptions
using tools a newcomer is not even aware about.

I'm aware that the target user group I have in mind and who thanked me
for the easy way to install their packages is quite small amongst all
users of Debian.  On the other hand Debian is quite popular in this
target user group compared to other distributions and this is because we
provide explicit care for this user group.

Kind regards

       Andreas.

-- 
http://fam-tille.de

Message #209 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: Steve McIntyre <steve@einval.com>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 20:13:53 +0100

]] Steve McIntyre 

> etc. I've pondered about how to do achieve that with the existing
> debconf code, but not got very far yet. Including more descriptive
> text and maybe even screen shots with each would be very helpful.

Debconf has support for pluggable UI widgets, so somebody could do this
without _too_ much work in the graphical version if they wanted, with
fallback code for the curses and text versions.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #214 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Andreas Tille <andreas@fam-tille.de>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 06 Dec 2016 20:43:58 +0100

[Message part 1 (text/plain, inline)]

Andreas Tille <andreas@fam-tille.de> writes:

> Hi Bdale,
>
> On Tue, 06 Dec 2016 08:10:37 -0700 Bdale Garbee wrote:
>> the first piece of advice I give most new-to-Debian users I'm helping out
>> personally is to just ignore the concept of tasks and pick software they
>> actually want on their system.
>
> To solve this very problem we actually invented the tasks in Blends:  It
> simply helps picking the software users want on their system without
> browsing the n (insert number of binary packages here) descriptions
> using tools a newcomer is not even aware about.
>
> I'm aware that the target user group I have in mind and who thanked me
> for the easy way to install their packages is quite small amongst all
> users of Debian.  On the other hand Debian is quite popular in this
> target user group compared to other distributions and this is because we
> provide explicit care for this user group.

Could we serve their needs with an extra debian-installer/blend preseed
to deal with this, probably aliased as just 'blend' so that one could
type something like:

  <TAB>blend=med<RETURN>

when booting the default media to get the desired result?

If we then made the ISOs easy to tweak, so that the default option
on the Debian-Med ISOs included blend=med on the command line by
default, would that actually be better than what we have, and also allow
us to drop the problematic tasksel items?

By easy to tweak, I mean making sure that there's enough room in the
menu files so that one could edit the ISO file directly and populate the
blend=... setting somehow.

Failing that, it's definitely possible to rebuild the images, and also
tell people about typing TAB and the 'blend=...' bit if they want to
install using standard Debian media.

I don't think that would take much to implement, and would not be adding
translatable strings to d-i, so might even be possible to do for stretch
(well, the preseed bit anyway)

If that scratches the itch, we could then drop the extra stuff from the
tasksel menu.

It also occurs to me that if we make sure that the handling of
debian-installer/blend were able to deal with pulling in extra udebs, as
one would need to in order to deal with blend=edu, one could have a new
udeb for asking about all the blends we know about, and pull that in
with something like blend=blends -- then if someone wants to be
presented with a vast menu of blends to choose from that can be done
without annoying normal users.

There could be an option for "Prompt me for all blends" in the Advanced
Menu, or we could just expect people to type blend=blends and/or produce
a "Blend-tastic!" variant of the install media.

If there's a real use case for mixing multiple blends, one could
separate them with ; as we do elsewhere, so:

  blend=med;ham;games

(we might want to call it 'blends' in that case, but I think that might
be over-complicating things)

Does that sound like it might be worth looking into?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #219 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: 846002@bugs.debian.org, tfheen@err.no

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 7 Dec 2016 08:45:28 +0100

Hi Tollef,

On 06.12.2016 17:04, Tollef Fog Heen wrote:
> ]] Ole Streicher 
> 
>> On 06.12.2016 10:37, Holger Levsen wrote:
>>> And this *is* still pretty confusing, though admitly better than it was
>>> half a year ago. 
>>
>> The current implementation has a popcon of >5000, without a single
>> complaint or confusion documented in the web within the last six months.
>> This is at least *some* empirical evidence that it is not "pretty
>> confusing", and again I would ask you to show any better empirical data
>> here to support your own point.
> 
> It's confusing enough that when I've had engineers from a provider
> install Debian for me, I have ended up with a desktop rather than server
> installation.  Should I have filed a bug about it?  Maybe.

I think you should, since this is the preferred way to let the
maintainer know about problems. This is even more true for prereleases
like alpha6 ff., since they depend on bugreports to get finished properly.

But this is not (completely) what I mean: I didn't only check for bug
reports, but also for help requests or comments. And the status is:
nobody had so much difficulties with the additional choices, that he
asked what to do. So, although the current way has been used by many
people, no difficulty was documented (with the exception I already
mentioned).

> I think it would be better if we moved most of tasksel out of the
> installer entirely and had an app store of some sort where applications
> and blends could all be better presented with screenshots and
> all. 

I disagree here: the installer is a kind-of assistent which leads you
through the installation process. It is much easier, even for me, to
follow these steps than to need to remember to start the app store
afterwards.

BTW, tasksel is able to do both: it is called from the installer, but
also max be called afterwards to change the selection if needed. IMO
this is the optimal way to interact with the user. It is just the
implementation that is hopelessly outdated.

> Again, I don't know how feasible it is to end up with a better design
> for stretch, but I don't think the current design is particularly
> scalable and should be replaced for buster.

Fully Ack. I see the current solution to integrate the Blends in Stretch
as a compromise for Stretch only; afterwards we should look to rewrite
tasksel for a better scalability.

Best regards

Ole

Message #224 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org, Andreas Tille <andreas@fam-tille.de>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 7 Dec 2016 08:59:53 +0100

Hi Philip,

On 06.12.2016 20:43, Philip Hands wrote:
> Could we serve their needs with an extra debian-installer/blend 
> preseed to deal with this, probably aliased as just 'blend' so that 
> one could type something like:
> 
> <TAB>blend=med<RETURN>
> 
> when booting the default media to get the desired result?

I think this is really unergonomic, since people need to understand or
remember installer boot time options. Boot prompt options are magic for
many users, and they need to read the documentation to get this.

And it is not recoverable: imagine that someone forgets to put it there
or made a typo, he cannot go back and change this -- he has to go
through the full installation process again.

And it does not really *present* the blends to the user; he already
needs to know what is there.

> If we then made the ISOs easy to tweak, so that the default option
> on the Debian-Med ISOs included blend=med on the command line by 
> default, would that actually be better than what we have, and also 
> allow us to drop the problematic tasksel items?

Since I already answered this, I hope it is OK to just copy my old
argument here:

I am not convinced that it is a good solution: First, it multiplies the
whole image creation process by the number of blends. If we have 10
official architectures and (let's say) 5 blends to be included there,
they would then have to manage 60 images instead of 10, with all the
requirements that come out of this (installer manual, web page, updates,
web space etc.).

But it also gives a wrong sign: Debian Pure Blends are by definition
integral part of Debian itself. But even now, this is hard to understand
for many people -- questions like "what is the difference between Debian
Astro and Debian" are quite common, even in front of a poster describing
exactly that. With having separate official images for all blends,
people would even be more confused. As an example, I would take the
Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
installation options -- people usually think that they have to
re-install the system if they want to switch from one flavour to the
other. Having similar experience with Debian would be bad for the
reputation of the Blends, and for Debian in general.

Best regards

Ole

Message #229 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: 846002@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 7 Dec 2016 09:32:06 +0100

On 06.12.2016 20:13, Tollef Fog Heen wrote:
> Debconf has support for pluggable UI widgets, so somebody could do this
> without _too_ much work in the graphical version if they wanted, with
> fallback code for the curses and text versions.

In principle, you are true. One of the reasons that I pushed the
debian-blends-tasks.desc in spring already was that we can see whether
this solution is a good compromise, of if we need to do further changes.

For the moment, I don't see pluggable UI widgets as an option anymore:
this would either mean to rewrite much of tasksel, or to add another
step (--> a new program/package) to the installer. With the ongoing
freeze, this doesn't sound realistic. For Buster, we should think about
a significant tasksel change, however.

Best regards

Ole

Message #234 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 07 Dec 2016 09:24:45 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> writes:

...
> Fully Ack. I see the current solution to integrate the Blends in Stretch
> as a compromise for Stretch only; afterwards we should look to rewrite
> tasksel for a better scalability.

I think the current list of three is not much worse than it already was.

It could be much improved by making it more obvious that the heading is
a heading.  Even if we're unable to stop headings having a checkbox, we
could change the text and the hierarchy slightly to be something like
this:

	[ ]  === Debian Desktop Environments:
	[x]  ... Gnome
	[ ]  ... Xfce
	[ ]  ... KDE
	[ ]  ... Cinnamon
	[ ]  ... MATE
	[ ]  ... LXDE
	[ ]  ... LXQt
        [ ]  === Common tasks:
	[ ]  ... web server
	[ ]  ... SSH server
	[x]  ... standard system utilities
	[ ]  === Special tasks (a.k.a Blends):
	[ ]  ... astronomy (Debian Astro)
	[ ]  ... games and fun (Debian Games)
	[ ]  ... life sciences and medicine (Debian Med)

That looses the (apparently useless) print server, to avoid making the
menu any longer, and uses the line for another header (suggestions for a
better name welcome).

It also explicitly rather than implicitly selects Gnome so it's obvious
what we mean.

The desktop= preseed might be broken by that, but I suspect that it's
already broken from my recent test (I need to confirm that), so we
should probably make sure that that works and then make sure that it
also works for one to specify e.g. desktop=kde and have KDE selected by
default in this menu in that case.

I don't know how well speakup, or the other UIs might deal with '==='.

Would that cheer people up without needing a major rewrite of tasksel?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #239 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org, Andreas Tille <andreas@fam-tille.de>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 07 Dec 2016 09:42:27 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> writes:

> Hi Philip,
>
> On 06.12.2016 20:43, Philip Hands wrote:
>> Could we serve their needs with an extra debian-installer/blend 
>> preseed to deal with this, probably aliased as just 'blend' so that 
>> one could type something like:
>> 
>> <TAB>blend=med<RETURN>
>> 
>> when booting the default media to get the desired result?
>
> I think this is really unergonomic, since people need to understand or
> remember installer boot time options. Boot prompt options are magic for
> many users, and they need to read the documentation to get this.
>
> And it is not recoverable: imagine that someone forgets to put it there
> or made a typo, he cannot go back and change this -- he has to go
> through the full installation process again.
>
> And it does not really *present* the blends to the user; he already
> needs to know what is there.
>
>> If we then made the ISOs easy to tweak, so that the default option
>> on the Debian-Med ISOs included blend=med on the command line by 
>> default, would that actually be better than what we have, and also 
>> allow us to drop the problematic tasksel items?
>
> Since I already answered this, I hope it is OK to just copy my old
> argument here:
>
> I am not convinced that it is a good solution: First, it multiplies the
> whole image creation process by the number of blends.

That's not what I had in mind -- if we make the images trivially
tunable, then one only actually needs to generate one image.  The
offering of specialised images could also be optimised by doing the edit
on the fly in the webserver.

It would certainly be a waste space on dumb mirror servers though.

> But it also gives a wrong sign: Debian Pure Blends are by definition
> integral part of Debian itself. But even now, this is hard to understand
> for many people -- questions like "what is the difference between Debian
> Astro and Debian" are quite common, even in front of a poster describing
> exactly that. With having separate official images for all blends,
> people would even be more confused. As an example, I would take the
> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
> installation options -- people usually think that they have to
> re-install the system if they want to switch from one flavour to the
> other. Having similar experience with Debian would be bad for the
> reputation of the Blends, and for Debian in general.

That's a very good point.  Fair enough.

Perhaps we need an aditional option at the boot prompt for a vanilla
install, that sets priority=critical or some such, so that one gets the
equivalent of hitting return thoughout the installer, and only get
prompted for the user & passwords, the point at which you're going to
trash your disk, and not much else.

That would deal with the case of people that might be upset by too much
choice, and then having more choice of blends would be less of an issue.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #244 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>, Andreas Tille <andreas@fam-tille.de>

Subject: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 7 Dec 2016 14:16:47 +0000

Philip Hands writes ("Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)"):
> Perhaps we need an aditional option at the boot prompt for a vanilla
> install, that sets priority=critical or some such, so that one gets the
> equivalent of hitting return thoughout the installer, and only get
> prompted for the user & passwords, the point at which you're going to
> trash your disk, and not much else.

I don't think the current installer asks too many questions.  The
timezone and locale are unavoidable.  The disk partitioning is
unavoidable unless you want to make an express-disk-wiper image :-).

Perhaps the right answer is to prefix the tasksel question with a
pre-question, asking the user to choose between
   Default desktop install
   Choose selection(s) of packages ("tasks")

Then the tasksel menu becomes less critical.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Message #249 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Cc: Philip Hands <phil@hands.com>, Andreas Tille <andreas@fam-tille.de>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 09:33:04 +0100

On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
> But it also gives a wrong sign: Debian Pure Blends are by definition
> integral part of Debian itself. But even now, this is hard to understand
> for many people -- questions like "what is the difference between Debian
> Astro and Debian" are quite common, even in front of a poster describing
> exactly that. With having separate official images for all blends,
> people would even be more confused. As an example, I would take the
> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
> installation options -- people usually think that they have to
> re-install the system if they want to switch from one flavour to the
> other. Having similar experience with Debian would be bad for the
> reputation of the Blends, and for Debian in general.

I don't agree with this argument.

Yes, indeed, in Ubuntu people often don't know that they don't really
need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
that really a problem?

It's certainly *easier* for users to understand that if they want X, Y,
or Z, they just need to install from the X, Y, or Z image. We can
present them with a message at the end of the installation, or add some
documentation, or whatever, to the effect that switching from one "type"
of Debian to another doesn't require a reinstall; but even if that's
what people end up doing, so what? I don't see the problem -- and it
*would* make this problem go away, since you lose the need for the
tasksel menu entirely.

After all, Ubuntu isn't the only distribution anymore which ships
several images; these days, if you want to install Fedora, you have to
choose between a "workstation", "server", or "atomic"/"cloud" image. It
seems to work for them.

I don't buy that presenting users with a choice of image to download
"confuses" them, when it in fact *takes away* a very confusing menu from
the installer. I think it's going to be obvious to people that if you
download, say, a Debian Med image, you're going to have a different
experience than if you download a "plain vanilla" Debian image; and
that's *certainly* going to make things easier for Debian Med users,
too.

Just my 2¢.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Message #254 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Wouter Verhelst <wouter@debian.org>, 846002@bugs.debian.org

Cc: Philip Hands <phil@hands.com>, Andreas Tille <andreas@fam-tille.de>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 10:26:27 +0100

On 08.12.2016 09:33, Wouter Verhelst wrote:
> On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
>> But it also gives a wrong sign: Debian Pure Blends are by definition
>> integral part of Debian itself. But even now, this is hard to understand
>> for many people -- questions like "what is the difference between Debian
>> Astro and Debian" are quite common, even in front of a poster describing
>> exactly that. With having separate official images for all blends,
>> people would even be more confused. As an example, I would take the
>> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
>> installation options -- people usually think that they have to
>> re-install the system if they want to switch from one flavour to the
>> other. Having similar experience with Debian would be bad for the
>> reputation of the Blends, and for Debian in general.
> 
> I don't agree with this argument.
> 
> Yes, indeed, in Ubuntu people often don't know that they don't really
> need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
> that really a problem?

Yes. In the whole 12 years of Ubuntu, they didn't succeed to make clear
that [KXG]Ubuntu is not different from Ubuntu except for the package
selection. I don't know how important it is for them to keep the unity
-- maybe they don't care here much.

But for Debian Pure Blends, it is important to have it clear that the
Pure Blends are just plain ("Pure") Debian. We don't just use the Debian
infrastructure to do something else -- we are an integrated part.
DebianMed and Debian Astro are in no way different from Debian, and if
you have Debian, then you have the Debian Pure Blends as well: it is
just a matter of package selection (and, ofcourse, mainly having the
special packages for our fields available).

And I still think that it would be horrible, if someone wanting to
switch to or from a Pure Blend would feel the need of re-installing.

The argument of wanting more than one blend installed at the same time
(not so rare within interdisciplinary teams) comes on top of that.

> It's certainly *easier* for users to understand that if they want X, Y,
> or Z, they just need to install from the X, Y, or Z image.

So, if they want KDE, they should just need to install a KDE Debian image?

The idea of the Debian Pure Blends is much similar to the idea of the
Desktop environments: There is no "KDE Debian", there is "just" a K
Desktop Environemnt in Debian. Similarly, the is no "Astro-Debian".
There is just a useful environment for astronomers in Debian.

And, having extra images per blend would multiply the number of images
we have to maintain. Instead of 10 official architectures, we would have
10 + 10 * number_of_blends. Possibly again multiplied by the number of
desktop environments, if we apply the same argument to them.
I am not sure that the cdimage team would be happy about this.

> I don't buy that presenting users with a choice of image to download
> "confuses" them, when it in fact *takes away* a very confusing menu from
> the installer. 

I would again ask to present some empirical data that adding the Blends
menu is "very confusing". The menu is there since quite a while, and it
was presented to many people, and we usually *do* get a response if
nobody understands the installation process. So, where are the complaints?

After eight months of testing, we can compare the fears here with the
collected experience. And this just doesn't support the fears.

> I think it's going to be obvious to people that if you
> download, say, a Debian Med image, you're going to have a different
> experience than if you download a "plain vanilla" Debian image; and
> that's *certainly* going to make things easier for Debian Med users,
> too.

The experience when installing Debian Astro is just Debian. It only adds
a useful selection of software on top of that, so that you immediately
can start your research, but aside from that everything is as everywhere.

So, the difference here is even less than the difference in experiencing
different desktop environments.

And my experience is that it is easier if people ask about how to
install Debian Astro, I can tell "Just select it in the last step of the
normal installer", instead of "Go to our home page, download a separate
image from there, and install this". It actually makes much difference
if the users can "feel" that they are just inside Debian, and not in a
special distribution.

Best regards

Ole

Message #259 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tille@debian.org>

To: Wouter Verhelst <wouter@debian.org>

Cc: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org, Philip Hands <phil@hands.com>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 11:13:40 +0100

On Thu, Dec 08, 2016 at 09:33:04AM +0100, Wouter Verhelst wrote:
> 
> It's certainly *easier* for users to understand that if they want X, Y,
> or Z, they just need to install from the X, Y, or Z image. ...

This argument implies an *exclusive* or which is definitely not the
case.  From the very beginning of the Blends effort (before it even was
called Blends) it was a goal to make Blends metapackages co-installable.
Besides the artificial example that an astronomer might want to install
at home also some Debian Jr. tasks it makes perfectly sense to install
Debian Science in addition to any science oriented Blend.

While I agree that since everything is pure Debian and can be installed
on top of any specific Blend image it does not follow the mindset we had
agreed upon.

Kind regards

     Andreas.

-- 
http://fam-tille.de

Message #264 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org, Wouter Verhelst <wouter@debian.org>, 846002@bugs.debian.org

Cc: Andreas Tille <andreas@fam-tille.de>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 08 Dec 2016 11:37:21 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> writes:

> On 08.12.2016 09:33, Wouter Verhelst wrote:
>> On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
>>> But it also gives a wrong sign: Debian Pure Blends are by definition
>>> integral part of Debian itself. But even now, this is hard to understand
>>> for many people -- questions like "what is the difference between Debian
>>> Astro and Debian" are quite common, even in front of a poster describing
>>> exactly that. With having separate official images for all blends,
>>> people would even be more confused. As an example, I would take the
>>> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
>>> installation options -- people usually think that they have to
>>> re-install the system if they want to switch from one flavour to the
>>> other. Having similar experience with Debian would be bad for the
>>> reputation of the Blends, and for Debian in general.
>> 
>> I don't agree with this argument.
>> 
>> Yes, indeed, in Ubuntu people often don't know that they don't really
>> need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
>> that really a problem?
>
> Yes. In the whole 12 years of Ubuntu, they didn't succeed to make clear
> that [KXG]Ubuntu is not different from Ubuntu except for the package
> selection. I don't know how important it is for them to keep the unity
> -- maybe they don't care here much.
>
> But for Debian Pure Blends, it is important to have it clear that the
> Pure Blends are just plain ("Pure") Debian. We don't just use the Debian
> infrastructure to do something else -- we are an integrated part.

On reflection, I agree wholeheartedly, and probably should not have
revisited the specialised CDs as an idea.  Sorry about that.

It would be depressing if Astrophysicists who used Debian-astro at work
were confused into downloading again because they fancy playing some
games at home, when the only difference between the images would be
about 5 bytes of preseed setting.

That said, it would probably be nice to make it trivially easy to set
downloaded media to default to e.g. debian-astro at the user's
preference, so that someone could do that and hand the result to a
colleague, saying "Just install that".  That's not the same thing as
publishing them like that though.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #269 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>, tille@debian.org, bubulle@debian.org, kibi@debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 18:27:46 +0100

So I have been following this whole discussion and I would like to
provide my input to Ole and the blends team.

- adding a new important package to work-around the fact that tasksel
  maintainers were busy/inactive was not a good move. As you all
  noted, the list of blends does not change often enough to warrant
  separate maintenance. And by doing that you circumvented the
  review by the debian-installer team which clearly has made design
  choices to keep the installer simple.

- the tasksel list with or without the blends already grew and can be
  confusing for new users, it should not be shown by default but should
  be offered as an option in all cases. See below for my suggestion.

- trying to keep blends-tasks now because we have no better option on the
  table right now is not a good move either. Had you not circumvented the
  d-i review at the time you introduced blends-tasks, then maybe you could
  have advertised the limitation of tasksel and we could have found sooner
  someone willing to fix this even if nobody in the blends team had the
  required skills...

I'm thus suggesting that blends-tasks should be removed and merged in
tasksel-data. At the same time, we should fix the installer to bypass
that confusing tasksel screen that we always get by default.

On Wed, 07 Dec 2016, Philip Hands wrote:
> It could be much improved by making it more obvious that the heading is
> a heading.  Even if we're unable to stop headings having a checkbox, we
> could change the text and the hierarchy slightly to be something like
> this:
> 
> 	[ ]  === Debian Desktop Environments:
> 	[x]  ... Gnome
[...]
> Would that cheer people up without needing a major rewrite of tasksel?

That would be a good change, yes.

But more importantly, we need to not show that page at all. I would like
to suggest a first screen:

Install packages for a:

  [X] standard desktop
  [ ] standard server
  [ ] minimal server
  [ ] Show me more options

You only see "tasksel" if you check the "Show me more options" which
should be unchecked by default. There's code that translates each option
into default selections at the tasksel level.

For instance, if you check "standard desktop" (checked by default like
currently, then it enables the "GNOME" task (or whatever was set in the
"desktop" kernel command line option) and the "standard installation".

If you check standard server, then you get "standard" + "ssh".
If you check minimal server, then you get only "ssh".

If you select "Show me more options", you can see the effect of each
option as you have some tasks already selected.

If we do that, then IMO it's fine if the tasksel screen is also cluttered
with blends.

Christian and Cyril, what are your thoughts on this? Do you think that if
we come up with a patch implementing the above, we could get it in
stretch? What would be the last delay to come up with such a patch?

Anyone up for the challenge?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #274 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 21:45:01 +0100

On 08.12.2016 18:27, Raphael Hertzog wrote:
> - trying to keep blends-tasks now because we have no better option on the
>   table right now is not a good move either. Had you not circumvented the
>   d-i review at the time you introduced blends-tasks, then maybe you could
>   have advertised the limitation of tasksel and we could have found sooner
>   someone willing to fix this even if nobody in the blends team had the
>   required skills...

The current solution was announced in bug #758116, which at that time
was assigned to tasksel, so you will find it in your mail archive. In
this bug, there is also a discussion about the limitations of tasksel
(starting in 2014, which is probably soon enough!), and also some
statements from the d-i team that they will probably not have time to
implement something here.

There is (and was) no circumvention of a d-i review. The menu is
available, and you can always review it and file a bug if it has a
problem -- like for any other aspect in Debian. This didn't happen for
the blends-tasks package so far. This shows that either the problems
were not big enough, or that d-i just had no time to do so. In the
latter case, I don't see why d-i would have more time if the tasks menu
would be in tasksel-data.

In my opinion it *is* a good idea to spread responsibilites; especially
when one team is overloaded and the topic fits so well into the field of
another team. And I see no advantage to move the responsibility of the
blends submenu back from the blends team to d-i.

> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
> 
> Install packages for a:
> 
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options
> 
> You only see "tasksel" if you check the "Show me more options" which
> should be unchecked by default. There's code that translates each option
> into default selections at the tasksel level.

If this could be implemented in Stretch, it would be a good compromise.

Best regards

Ole

Message #279 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Raphael Hertzog <hertzog@debian.org>

Cc: Philip Hands <phil@hands.com>, 846002@bugs.debian.org, Ole Streicher <olebole@debian.org>, tille@debian.org, bubulle@debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 23:20:16 +0100

[Message part 1 (text/plain, inline)]

Hi Raphaël and all,

Raphael Hertzog <hertzog@debian.org> (2016-12-08):
> I'm thus suggesting that blends-tasks should be removed and merged in
> tasksel-data. At the same time, we should fix the installer to bypass
> that confusing tasksel screen that we always get by default.
> 
> On Wed, 07 Dec 2016, Philip Hands wrote:
> > It could be much improved by making it more obvious that the heading is
> > a heading.  Even if we're unable to stop headings having a checkbox, we
> > could change the text and the hierarchy slightly to be something like
> > this:
> > 
> > 	[ ]  === Debian Desktop Environments:
> > 	[x]  ... Gnome
> [...]
> > Would that cheer people up without needing a major rewrite of tasksel?
> 
> That would be a good change, yes.
> 
> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
> 
> Install packages for a:
> 
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options
> 
> You only see "tasksel" if you check the "Show me more options" which
> should be unchecked by default. There's code that translates each option
> into default selections at the tasksel level.
> 
> For instance, if you check "standard desktop" (checked by default like
> currently, then it enables the "GNOME" task (or whatever was set in the
> "desktop" kernel command line option) and the "standard installation".
> 
> If you check standard server, then you get "standard" + "ssh".
> If you check minimal server, then you get only "ssh".
> 
> If you select "Show me more options", you can see the effect of each
> option as you have some tasks already selected.
> 
> If we do that, then IMO it's fine if the tasksel screen is also cluttered
> with blends.
> 
> Christian and Cyril, what are your thoughts on this? Do you think that if
> we come up with a patch implementing the above, we could get it in
> stretch? What would be the last delay to come up with such a patch?

While it's clear to me we need to fix the blends situation at some point
before the release (couldn't find time to do so yet; last resort option
is masking all of them entirely), I'm rather dubious about changing the
package selection/tasksel screen at this point of the release cycle.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #284 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 22:45:01 +0000

[Message part 1 (text/plain, inline)]

On Thu, Dec 08, 2016 at 06:27:46PM +0100, Raphael Hertzog wrote:
> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
> 
> Install packages for a:
> 
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options

/me likes. Thanks, Raphael.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #289 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Christian PERRIER <bubulle@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, Philip Hands <phil@hands.com>, 846002@bugs.debian.org, Ole Streicher <olebole@debian.org>, tille@debian.org, kibi@debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Thu, 8 Dec 2016 18:59:42 +0100

[Message part 1 (text/plain, inline)]

Quoting Raphael Hertzog (hertzog@debian.org):

> Christian and Cyril, what are your thoughts on this? Do you think that if
> we come up with a patch implementing the above, we could get it in
> stretch? What would be the last delay to come up with such a patch?


From my own POV, I'm too far from core D-I development (except l10n)
nowadays to get a usefuul advice. When it comes at tasksel, I work in
low maintenance mode. When obvious things pop up, and if I notice
them, I usually apply fixes. The same stands when an upload is needed.

However, when it comes at design issues, I consider that my own advice
would be quite pointless and maybe even confusing.

Sorry for not being very helpful here.

[signature.asc (application/pgp-signature, inline)]

Message #294 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Raphael Hertzog <hertzog@debian.org>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>, tille@debian.org, bubulle@debian.org, kibi@debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Fri, 09 Dec 2016 08:37:11 +0100

[Message part 1 (text/plain, inline)]

Raphael Hertzog <hertzog@debian.org> writes:

> So I have been following this whole discussion and I would like to
> provide my input to Ole and the blends team.
>
> - adding a new important package to work-around the fact that tasksel
>   maintainers were busy/inactive was not a good move. As you all
>   noted, the list of blends does not change often enough to warrant
>   separate maintenance. And by doing that you circumvented the
>   review by the debian-installer team which clearly has made design
>   choices to keep the installer simple.
>
> - the tasksel list with or without the blends already grew and can be
>   confusing for new users, it should not be shown by default but should
>   be offered as an option in all cases. See below for my suggestion.
>
> - trying to keep blends-tasks now because we have no better option on the
>   table right now is not a good move either. Had you not circumvented the
>   d-i review at the time you introduced blends-tasks, then maybe you could
>   have advertised the limitation of tasksel and we could have found sooner
>   someone willing to fix this even if nobody in the blends team had the
>   required skills...
>
> I'm thus suggesting that blends-tasks should be removed and merged in
> tasksel-data. At the same time, we should fix the installer to bypass
> that confusing tasksel screen that we always get by default.
>
> On Wed, 07 Dec 2016, Philip Hands wrote:
>> It could be much improved by making it more obvious that the heading is
>> a heading.  Even if we're unable to stop headings having a checkbox, we
>> could change the text and the hierarchy slightly to be something like
>> this:
>> 
>> 	[ ]  === Debian Desktop Environments:
>> 	[x]  ... Gnome
> [...]
>> Would that cheer people up without needing a major rewrite of tasksel?
>
> That would be a good change, yes.
>
> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
>
> Install packages for a:
>
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options

I think that should be a select, rather than a multi-select:

 -->  standard desktop (will install $DESKTOP)  <--
      standard server  (includes ssh)
      other use cases

(or however the UI presents it)

The reason for the extra bits in brackets is that I've always thought
the tasksel menu was hiding just a little too much of what was meant by
the options.

The reason to use "other use cases" is that eventually I think that
option should take you to a blends menu, where the first blend could be
a fake custom ("Custom selection of tasks" or similar) blend that drops
you into tasksel.  For now the tasksel menu as it stands will clearly do
the job, and will require least work if left alone.

I think it's better to drop the minimal server option at this level as
people wanting that probably know what they're doing, and will quite
often be preseeding anyway.

In the end, I think it might be worth treating desktop and server as
blends too, to make the logic less messy, but that's probably something
to look into after stretch.

I would hope to have time to work on this -- once I stop running a
temperature with the cold that currently has me sitting in bed.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #299 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Philip Hands <phil@hands.com>, Raphael Hertzog <hertzog@debian.org>, 846002@bugs.debian.org

Cc: tille@debian.org, bubulle@debian.org, kibi@debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Fri, 9 Dec 2016 09:54:58 +0100

On 09.12.2016 08:37, Philip Hands wrote:
>> On Wed, 07 Dec 2016, Philip Hands wrote:
>>> It could be much improved by making it more obvious that the heading is
>>> a heading.  Even if we're unable to stop headings having a checkbox, we
>>> could change the text and the hierarchy slightly to be something like
>>> this:
>>>
>>> 	[ ]  === Debian Desktop Environments:
>>> 	[x]  ... Gnome
>> [...]
>>> Would that cheer people up without needing a major rewrite of tasksel?

This improves the situation, and could probably done quite simple at the
same place where the ellipsis (...) is introduced:

https://sources.debian.net/src/tasksel/3.38/tasksel.pl/#L360-L366

One just needs to find out here that it is actually a heading.

> I think that should be a select, rather than a multi-select:
> 
>  -->  standard desktop (will install $DESKTOP)  <--
>       standard server  (includes ssh)
>       other use cases
> 
> (or however the UI presents it)
> 
> The reason for the extra bits in brackets is that I've always thought
> the tasksel menu was hiding just a little too much of what was meant by
> the options.

I would vote for that, however we would need

1. someone willing *and* competent (the latter excludes myself) to
implement this in tasksel,

2. someone convincing Cyril that this is ready to go into Stretch:

On 08.12.2016 23:20, Cyril Brulebois wrote:
> While it's clear to me we need to fix the blends situation at some point
> before the release (couldn't find time to do so yet; last resort option
> is masking all of them entirely), I'm rather dubious about changing the
> package selection/tasksel screen at this point of the release cycle.

Volunteers for any of those tasks?

Best regards

Ole

Message #304 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>

Cc: tille@debian.org, bubulle@debian.org, kibi@debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 10 Dec 2016 01:03:56 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> writes:

> On 09.12.2016 08:37, Philip Hands wrote:
>>> On Wed, 07 Dec 2016, Philip Hands wrote:
>>>> It could be much improved by making it more obvious that the heading is
>>>> a heading.  Even if we're unable to stop headings having a checkbox, we
>>>> could change the text and the hierarchy slightly to be something like
>>>> this:
>>>>
>>>> 	[ ]  === Debian Desktop Environments:
>>>> 	[x]  ... Gnome
>>> [...]
>>>> Would that cheer people up without needing a major rewrite of tasksel?
>
> This improves the situation, and could probably done quite simple at the
> same place where the ellipsis (...) is introduced:
>
> https://sources.debian.net/src/tasksel/3.38/tasksel.pl/#L360-L366
>
> One just needs to find out here that it is actually a heading.
>
>> I think that should be a select, rather than a multi-select:
>> 
>>  -->  standard desktop (will install $DESKTOP)  <--
>>       standard server  (includes ssh)
>>       other use cases
>> 
>> (or however the UI presents it)
>> 
>> The reason for the extra bits in brackets is that I've always thought
>> the tasksel menu was hiding just a little too much of what was meant by
>> the options.
>
> I would vote for that, however we would need
>
> 1. someone willing *and* competent (the latter excludes myself) to
> implement this in tasksel,

Just to test things out, if one adds:

  url=hands.com/d-i/bug/846002/preseed.cfg

to the kernel command line (so, hitting TAB as the installer's boot menu)
it will tweaks d-i to have such a menu.

I suspect that the way it works could be improved (it could probably be
plumbed into tasksel itself) but it seems to do the trick, and should
let people have a play and give feedback without needing to create new
.iso images.

I've tried it interactively, but not yet with preseeding, which will
need either this to be changed to chain into your preseed, or vice versa
(if you can work out how, feel free to give that a try and see if you
can find what it breaks :-) ).

The files that do the trick are here:  http://hands.com/d-i/bug/846002/

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #309 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>

Cc: tille@debian.org, bubulle@debian.org, kibi@debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 10 Dec 2016 11:06:30 +0100

Hi Phil,

On 10.12.2016 01:03, Philip Hands wrote:
> Just to test things out, if one adds:
> 
>   url=hands.com/d-i/bug/846002/preseed.cfg
> 
> to the kernel command line (so, hitting TAB as the installer's boot menu)
> it will tweaks d-i to have such a menu.

To me, this looks like a very nice solution! In the tasksel screen, the
"back" button was enabled for the first time, but produced an error and
brought me back to the list of installation steps.

Going through the sofware selection a second time made the back button
disappear. I have absolutely no experience with preseeding, so I can't
test it more than the interactive use case.

The advantage of your solution is that one doesn't need to touch tasksel
itself, which may address Cyrils doubts. And since Holger also seems to
be happy with this solution: maybe we could focus on this in the further
discussion?

Best regards

Ole

Message #314 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 10 Dec 2016 12:06:44 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> writes:

> Hi Phil,
>
> On 10.12.2016 01:03, Philip Hands wrote:
>> Just to test things out, if one adds:
>> 
>>   url=hands.com/d-i/bug/846002/preseed.cfg
>> 
>> to the kernel command line (so, hitting TAB as the installer's boot menu)
>> it will tweaks d-i to have such a menu.
>
> To me, this looks like a very nice solution! In the tasksel screen, the
> "back" button was enabled for the first time, but produced an error and
> brought me back to the list of installation steps.
>
> Going through the sofware selection a second time made the back button
> disappear. I have absolutely no experience with preseeding, so I can't
> test it more than the interactive use case.

Thanks for testing that, and don't worry about the preseeding bit.
It's far from straight-forward, even for people that know what they're
doing.

I agree that the back buttons don't work (and should do, so that one can
glance at tasksel and realise that you should bail out and select a
simple option).

I think it will need to be put into the scripts in tasksel itself to fix
that, which will also remove the bits of the script that I'm unhapy
about anyway (chrooting to set preseeds).

That being the case, there's not much point testing with preseeding, as
it's not going to be implemented like this, so this should just be
considered a demonstration for now.

Anyway, having done it, my first impression (which I'm surprised by) is
that the list is too short -- I think that it is perhaps because it is
much easier to select one option from a list than it is to decide what
combination of options one wants.

How about one or both of:

  bare-bones     -- nothing selected
  minimal-server -- ssh and nothing else

Is there any objective way of working out what other combinations would
be popular, rather than just guessing?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #319 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 846002@bugs.debian.org

Subject: Bug#846002: blends-tasks must not be priority:important

Date: Sat, 10 Dec 2016 13:18:51 +0100

[Message part 1 (text/plain, inline)]

While I have no opninion on whether blend-tasks is important enough to
have installed by default,  I would urge to revisit the idea to (mis)use
the package priority to achieve that.

If a package was pulled in by debootstrap because of its priority, it's
marked as manually installed.
This is usually bad, because say later on you decide that you want to
change the name of the package or implement this differently, the
manually installed package sticks around.

So, assuming blend-tasks is important enough to be installed by default,
please think of another way to pull it in.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #324 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 10 Dec 2016 14:00:12 +0100

Hi Phil,

On 10.12.2016 12:06, Philip Hands wrote:
> Anyway, having done it, my first impression (which I'm surprised by) is
> that the list is too short -- I think that it is perhaps because it is
> much easier to select one option from a list than it is to decide what
> combination of options one wants.

My feeling is exactly the opposite: the having the two most prominent
options there is (if they have good names), with the "90% standard"
preselected seems simple enough; in the discussion of this bug there was
even the proposal (as I remember) to have just *one* option, which also
would not be too bad: Most people probably don't care here anyway to
select something, and just having *one* checkbox here would give room
for a detailed explanation what is going to be installed then.

Then, even the "server" would move to the "extended" selection --
servers are usually installed by more experienced users which can deal
with more options.

In any case, I would like to hear the opinion of Cyril or other d-i
people here.

Best regards

Ole

Message #329 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Michael Biebl <biebl@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important

Date: Sat, 10 Dec 2016 14:15:51 +0100

Hi Michael,

On 10.12.2016 13:18, Michael Biebl wrote:
> While I have no opninion on whether blend-tasks is important enough to
> have installed by default,  I would urge to revisit the idea to (mis)use
> the package priority to achieve that.

That is the standard way how tasksel gets its menu: tasksel-data is
marked as "important" and that way it finds its way onto the installer
image. So, all arguments you have here are also valid for the default
tasks. If we think this is wrong, we should get a completely different
solution here -- which is IMO outside of the scope of this bug.

> If a package was pulled in by debootstrap because of its priority, it's
> marked as manually installed.
> This is usually bad, because say later on you decide that you want to
> change the name of the package or implement this differently, the
> manually installed package sticks around.

But this problem is true for all manually installed package, right? So,
a manually installed iceweasel would have a renaming problem as well.
Couldn't it be solved by a transitional package?  I would also consider
this as not being release critical.

The current solution would also have the advantage that people who
actually hate the blends task list (like Holger Levsen: "I will get used
to type 'apt remove blends-tasks' as well.") have the possibility to
remove that from the tasks selection list. So, this would probably have
more acceptance than a solution where the blends tasks are glued into
the main task selection.

Best regards

Ole

Message #334 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important

Date: Sat, 10 Dec 2016 14:48:24 +0100

[Message part 1 (text/plain, inline)]

Am 10.12.2016 um 14:15 schrieb Ole Streicher:
> Hi Michael,
> 
> On 10.12.2016 13:18, Michael Biebl wrote:
>> While I have no opninion on whether blend-tasks is important enough to
>> have installed by default,  I would urge to revisit the idea to (mis)use
>> the package priority to achieve that.
> 
> That is the standard way how tasksel gets its menu: tasksel-data is
> marked as "important" and that way it finds its way onto the installer
> image. So, all arguments you have here are also valid for the default
> tasks. If we think this is wrong, we should get a completely different
> solution here -- which is IMO outside of the scope of this bug.

Well, two wrongs don't make one right.

An obvious solution seemed to me, to make tasksel(-*) depend on
blends-tasks. This why, the package would be marked as auto-installed,
and should you later decide to implement that differently, say directly
in tasksel, then tasksel can simply drop that dependency.
I assume though you have considered this obvious solution and decided
against it for some reason?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #339 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Michael Biebl <biebl@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important

Date: Sat, 10 Dec 2016 15:07:07 +0100

Hi Michael,

On 10.12.2016 14:48, Michael Biebl wrote:
> Am 10.12.2016 um 14:15 schrieb Ole Streicher:
>> Hi Michael,
>>
>> On 10.12.2016 13:18, Michael Biebl wrote:
>>> While I have no opninion on whether blend-tasks is important enough to
>>> have installed by default,  I would urge to revisit the idea to (mis)use
>>> the package priority to achieve that.
>>
>> That is the standard way how tasksel gets its menu: tasksel-data is
>> marked as "important" and that way it finds its way onto the installer
>> image. So, all arguments you have here are also valid for the default
>> tasks. If we think this is wrong, we should get a completely different
>> solution here -- which is IMO outside of the scope of this bug.
> 
> Well, two wrongs don't make one right.

If we would remove one of them, the other would still stay there, and
the problem remains.

> An obvious solution seemed to me, to make tasksel(-*) depend on
> blends-tasks. This why, the package would be marked as auto-installed,
> and should you later decide to implement that differently, say directly
> in tasksel, then tasksel can simply drop that dependency.

The disadvantage is that people can't uninstall the blends task. And at
least Holger clearly indicated that he wants to have this option.

> I assume though you have considered this obvious solution and decided
> against it for some reason?

The major reason is that during the discussion of the blends into
tasksel became clear that the tasksel maintainers are already
overloaded. Having to manage the blends tasks here would put another
work on top of that. Additionally, they have no competence in deciding
neither which blends should go in, nor about how to describe them. This
all done by the Blends team. So, it seems to be natural for me to have
the blends tasks maintained by this team, and not by the tasksel developers.

In principle, the same would be applicable for the desktop selection,
however there seems to be no dedicated team for the desktop.

Best regards

Ole

Message #344 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Michael Biebl <biebl@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important

Date: Sat, 10 Dec 2016 15:20:10 +0100

Hi again,

sorry: missed one point:

On 10.12.2016 15:07, Ole Streicher wrote:
> On 10.12.2016 14:48, Michael Biebl wrote:
>> An obvious solution seemed to me, to make tasksel(-*) depend on
>> blends-tasks. This why, the package would be marked as auto-installed,
>> and should you later decide to implement that differently, say directly
>> in tasksel, then tasksel can simply drop that dependency.
>> I assume though you have considered this obvious solution and decided
>> against it for some reason?

If you mean here why we just didn't put blends-tasks as dependency into
tasksel-data: this wouldn't help, since the Policy says (§2.5):

"Packages must not depend on packages with lower priority values"

Since tasksel-data is Priority: important, blends-tasks would need to
have this priority as well.

Ole

Message #349 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important

Date: Sat, 10 Dec 2016 15:27:32 +0100

[Message part 1 (text/plain, inline)]

Am 10.12.2016 um 15:20 schrieb Ole Streicher:

> If you mean here why we just didn't put blends-tasks as dependency into
> tasksel-data: this wouldn't help, since the Policy says (§2.5):
> 
> "Packages must not depend on packages with lower priority values"
> 
> Since tasksel-data is Priority: important, blends-tasks would need to
> have this priority as well.

That part of the policy is non-sense and thankfully is in the process of
being fixed [1]. Library and helper packages should never be installed
because of their priority imho.
I deliberately violate that policy in various packages, fwiw.

Regards,
Michael

[I'll stop here since I don't want to derail the discussion to much,
just wanted to give my 2¢]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #354 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 10 Dec 2016 17:35:19 +0100

On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote:
> How about one or both of:
> 
>   bare-bones     -- nothing selected
>   minimal-server -- ssh and nothing else
> 
> Is there any objective way of working out what other combinations would
> be popular, rather than just guessing?

Note that the whole point of tasksel was, originally, to show just that.
Things have simply gotten out of hand.

If you're going to update tasksel, it might be good to keep that in
mind...

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Message #359 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Wouter Verhelst <wouter@debian.org>, 846002@bugs.debian.org

Cc: Philip Hands <phil@hands.com>, Ole Streicher <olebole@debian.org>

Subject: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sun, 11 Dec 2016 11:34:31 +0000

Wouter Verhelst writes ("Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)"):
> On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote:
> > How about one or both of:
> > 
> >   bare-bones     -- nothing selected
> >   minimal-server -- ssh and nothing else
> > 
> > Is there any objective way of working out what other combinations would
> > be popular, rather than just guessing?
> 
> Note that the whole point of tasksel was, originally, to show just that.
> Things have simply gotten out of hand.
> 
> If you're going to update tasksel, it might be good to keep that in
> mind...

Quite.  I thought Phil's original suggestion

  -->  standard desktop (will install $DESKTOP)  <--
       standard server  (includes ssh)
       other use cases

was good but perhaps even too long.  Anyone who wants anything ommore
complicated can cope with tasksel.  Even someone who wants a server
can very likely cope with tasksel.

Bear in mind that every option on this list needs to be read even by
the most inexperienced user.  There should be nothing on it that does
not need to be there.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Message #364 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Mon, 12 Dec 2016 10:07:36 +0100

[Message part 1 (text/plain, inline)]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Wouter Verhelst writes ("Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)"):
>> On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote:
>> > How about one or both of:
>> > 
>> >   bare-bones     -- nothing selected
>> >   minimal-server -- ssh and nothing else
>> > 
>> > Is there any objective way of working out what other combinations would
>> > be popular, rather than just guessing?
>> 
>> Note that the whole point of tasksel was, originally, to show just that.
>> Things have simply gotten out of hand.
>> 
>> If you're going to update tasksel, it might be good to keep that in
>> mind...
>
> Quite.  I thought Phil's original suggestion
>
>   -->  standard desktop (will install $DESKTOP)  <--
>        standard server  (includes ssh)
>        other use cases
>
> was good but perhaps even too long.  Anyone who wants anything ommore
> complicated can cope with tasksel.  Even someone who wants a server
> can very likely cope with tasksel.

Fair enough -- although I think it's quite good to include at least one
not-a-desktop option because it helps define what we mean by desktop.

People coming from windows are probably used to servers having a GUI,
for instance, so its probably worth mentioning that we mean that a
server won't have a GUI by default.  Of course finding a few words to
expres that in a way that's understandable to someone who's not sure
what "Desktop" is supposed to mean is not so easy.

BTW I've updated my menu hack -- it now is replacing the pkgsel.postinst
so is a much better representation of how things should work.

I tried to get the back button in tasksel to send you back to my
simple_tasksel menu, but weirdly tasksel seems not to return 10, as it
should, when you hit back.  That seems to be because the db_go inside
tasksel is not returning 30, as it should, which is very odd.  Perhaps
that's something to do with the fact that tasksel is running in the
chroot, but it should still be talking to the same debconf front end, so
I don't quite get haw that can go wrong -- the code that does all this
has not been touched in years, and I guess it worked when Joey wrote
it. Very odd.

Anyway, because of that, I've disabled the back button for now.

The menu is now:

--> standard ("${DESKTOP}") desktop                           <--
    standard server [text-only console & 'ssh' remote access]
    other use cases

I get the feeling that the 'standard' is pretty redundant, but just
'desktop' and 'server' seems wrong too.

I'm tempted to make the third option "All Other Routes" (or whatever the
locale has on it's road signs to indicate that you're heading out of
town)

Have a play and tell me what you think -- should work with any recent
media and adding:  url=hands.com/d-i/d-i/bug/846002/preseed.cfg

The code lurks here: http://git.hands.com/?p=hands-off.git;a%3Dshortlog;h%3Drefs/heads/new-unified3

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #369 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: Philip Hands <phil@hands.com>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 14 Dec 2016 18:07:12 +0100

]] Philip Hands 

> The menu is now:
> 
> --> standard ("${DESKTOP}") desktop                           <--
>     standard server [text-only console & 'ssh' remote access]
>     other use cases
> 
> I get the feeling that the 'standard' is pretty redundant, but just
> 'desktop' and 'server' seems wrong too.

As a data point: To me, as somebody who knows Debian reasonably well,
I'd associate «standard» with the priority level, which would make me
unlikely to want to choose that option, since it installs half the
universe.  I don't know whether your «standard + $X» options are
priority >= standard + the specific task, or if it's «base OS»
(debootstrap's base + kernel + boot loader, essentially) + $X.

> I'm tempted to make the third option "All Other Routes" (or whatever the
> locale has on it's road signs to indicate that you're heading out of
> town)

There is no such thing in my locale.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #374 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Thomas Hochstein <thh@inter.net>

To: Tollef Fog Heen <tfheen@err.no>

Cc: debian-ctte@lists.debian.org, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 17 Dec 2016 11:18:29 +0100

Tollef Fog Heen wrote:

> As a data point: To me, as somebody who knows Debian reasonably well,
> I'd associate «standard» with the priority level, which would make me
> unlikely to want to choose that option, since it installs half the
> universe.  

I'm not a native speaker, but would replacing "standard" by "default"
help to disambiguate?

-thh

Message #379 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: 846002@bugs.debian.org

Cc: "Cyril Brulebois" <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 10:41:20 +0100

[Message part 1 (text/plain, inline)]

Hi Cyril,

Just as a reminder for the upcoming alpha that I was trying to do
something about this by adding an extra simplified tasksel promt:

Philip Hands <phil@hands.com> writes:
...
> The menu is now:
>
> --> standard ("${DESKTOP}") desktop                           <--
>     standard server [text-only console & 'ssh' remote access]
>     other use cases

I just applied that as a patch to pkgsel and pushed it as pu/simple_tasksel

It just occurred to me that if we made the list of tasks for each choice
be in the template, then it avoids hard-wiring the tasks in the code,
and it should be easier to preseed, so might serve as a customisable menu
for the likes of debian-edu -- I've added that as a subsequent commit,
but that's yet to be tested.  I should have time to test that this evening.

The template needs proper anotation for translators.

I think it might well be better to replace 'standard' with 'default'.

BTW as it stands, the server option doesn't bother installing CUPS,
despite that being in the default tasksel set -- That was based on
Colin's comment that task-cups needs a rethink, and is currently a bit
useless.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #384 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Philip Hands <phil@hands.com>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 10:59:36 +0100

[Message part 1 (text/plain, inline)]

Hi,

Philip Hands <phil@hands.com> (2016-12-20):
> Just as a reminder for the upcoming alpha that I was trying to do
> something about this by adding an extra simplified tasksel promt:

Thanks. I need to allocate time to test this, which this week doesn't
permit.

Without having looked at it yet, I'll just state again that I'd like
to see minimal changes at this point of the freeze, and that dropping
blends entirely is still my default option in case proposed changes
have too far reaching consequences.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #389 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org, Philip Hands <phil@hands.com>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 11:55:04 +0100

Hi Cyril,

On 20.12.2016 10:59, Cyril Brulebois wrote:
> dropping blends entirely is still my default option in case proposed
> changes have too far reaching consequences.

As I already wrote several times: before you do so, please show some
evidence that in the half year that the current version of the installer
containing a blends selection has added an unacceptable amount of
confusion and that we can't solve that by changing the wording or such.

We already have more that 5700 popcon-counted installations with the
blends selection in the installer. This should give some base for that.

And at least by searching the net, I could not find anything.

Best regards

Ole

Message #394 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Ole Streicher <olebole@debian.org>

Cc: 846002@bugs.debian.org, Philip Hands <phil@hands.com>, Christian Perrier <bubulle@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 15:01:50 +0100

[Message part 1 (text/plain, inline)]

Hi,

Ole Streicher <olebole@debian.org> (2016-12-20):
> As I already wrote several times: before you do so, please show some
> evidence that in the half year that the current version of the installer
> containing a blends selection has added an unacceptable amount of
> confusion and that we can't solve that by changing the wording or such.

Having more choices means more confusion. Look at any UX studies, or
install parties.

Also, choices aren't consistent depending on installation media, which
doesn't help.

You might call it me being weird, but this is how we've tried to balance
choices in D-I for a few years (10+ AFAICT), as already confirmed by
Christian earlier. The addition of various blends in the path of all
users shifts this balance, in the wrong direction.

> We already have more that 5700 popcon-counted installations with the
> blends selection in the installer. This should give some base for
> that.

Surely, people asking for blends are using blends selection. That's nice
and I'm pretty sure nobody is going to dispute that. But that shouldn't
make d-i more confusing for others.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #399 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Cyril Brulebois <kibi@debian.org>

Cc: 846002@bugs.debian.org, Philip Hands <phil@hands.com>, Christian Perrier <bubulle@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 15:16:50 +0100

Hi Cyril,

On 20.12.2016 15:01, Cyril Brulebois wrote:
> Ole Streicher <olebole@debian.org> (2016-12-20):
>> As I already wrote several times: before you do so, please show some
>> evidence that in the half year that the current version of the installer
>> containing a blends selection has added an unacceptable amount of
>> confusion and that we can't solve that by changing the wording or such.
> 
> Having more choices means more confusion. Look at any UX studies, or
> install parties.
> 
> Also, choices aren't consistent depending on installation media, which
> doesn't help.
> 
> You might call it me being weird, but this is how we've tried to balance
> choices in D-I for a few years (10+ AFAICT), as already confirmed by
> Christian earlier. The addition of various blends in the path of all
> users shifts this balance, in the wrong direction.

And by how much? If it is just a very little bit, this could be acceptable.

It seems clear by the whole discussion that tasksel is *already* quite
confusing to the users in an unacceptable way, and that we should change
it in buster. So, whatever we do now is just the last step in a dead end.

BTW, adding LXQT to the desktops also goes into the wrong direction,
since it adds another choice. This shows, that you don't take the "wrong
direction" argument serious yourself (resp. Christian, who did the patch
in the tasksel git).

>> We already have more that 5700 popcon-counted installations with the
>> blends selection in the installer. This should give some base for
>> that.
> 
> Surely, people asking for blends are using blends selection. That's nice
> and I'm pretty sure nobody is going to dispute that. But that shouldn't
> make d-i more confusing for others.

So, please *show* that the current solution does add confusion in an
unacceptable way. Show for example installation reports. Or something
else which shows clearly that the current concrete solution in not
acceptable. Based on the concrete experience of the current installer.

And, I didn't just search through the astronomy related pages for
issues, but tried to catch any report for the new installer -- and
didn't find anything.

Again: the installer is there to test for 6 months now, but if it is
inacceptably bad: why are there no complaints?

Best regards

Ole

Message #404 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>, Philip Hands <phil@hands.com>, Christian Perrier <bubulle@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 14:16:13 +0000

On Tue, Dec 20, 2016 at 03:01:50PM +0100, Cyril Brulebois wrote:
>
>Ole Streicher <olebole@debian.org> (2016-12-20):
>
>> We already have more that 5700 popcon-counted installations with the
>> blends selection in the installer. This should give some base for
>> that.
>
>Surely, people asking for blends are using blends selection. That's nice
>and I'm pretty sure nobody is going to dispute that. But that shouldn't
>make d-i more confusing for others.

Nod. I *have* also seen users confused by the addition of the blends
into the tasksel list. A better split of the tasks (like Phil is
suggesting) would help a lot here.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Message #409 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Steve McIntyre <steve@einval.com>, Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org

Cc: Philip Hands <phil@hands.com>, Christian Perrier <bubulle@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 15:21:56 +0100

Hi Steve,

On 20.12.2016 15:16, Steve McIntyre wrote:
> I *have* also seen users confused by the addition of the blends

Can you be more specific here? Old wording (with many blends) or current
solution? What was the specific problem?

> into the tasksel list. A better split of the tasks (like Phil is
> suggesting) would help a lot here.

This is for sure. Cyril just states that he rather would love to remove
the blends completely, and this is something I am arguing against.

That Phils solution is a great compromise, is out of question. IMO it
would help much if d-i would help here a bit instead of just trying to
play a veto game.

Best regards

Ole

Message #414 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Cc: Cyril Brulebois <kibi@debian.org>, Philip Hands <phil@hands.com>, Christian Perrier <bubulle@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 14:27:42 +0000

[Message part 1 (text/plain, inline)]

On Tue, Dec 20, 2016 at 03:16:50PM +0100, Ole Streicher wrote:
> Again: the installer is there to test for 6 months now, but if it is
> inacceptably bad: why are there no complaints?

the complaints have been there for months, you just choose to consider
them invalid. some people dont like to repeat themselves.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #419 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Ole Streicher <olebole@debian.org>

Cc: Steve McIntyre <steve@einval.com>, 846002@bugs.debian.org, Philip Hands <phil@hands.com>, Christian Perrier <bubulle@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Tue, 20 Dec 2016 17:49:53 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> (2016-12-20):
> This is for sure. Cyril just states that he rather would love to remove
> the blends completely, and this is something I am arguing against.

No, I said this was the default action, until I have looked at proposed
changes, and assessed what to do with them.


Current state in the archive is a no-go. It's been the case for too many
releases already, and it's been reported as such from the very beginning.

Proposed implementation hasn't reached the master branch, let alone the
archive; and current commit messages contain interrogations AFAICT from a
quick look at the IRC notifications earlier today.

That's not something I want to see rushed into stretch just because
nobody worked on the no-go situation for months, despite early warnings.

> That Phils solution is a great compromise, is out of question. IMO it
> would help much if d-i would help here a bit instead of just trying to
> play a veto game.

It's not about veto-ing. It's about not believing it's OK to push/rush
invasive changes whenever one feels like it. The freeze is here for a
reason. Back a few years, we've had to change d-i a lot during the
freeze because almost nobody worked on it for quite a while. (We even went
as far as not starting the freeze until an Alpha was actually released, if
memory serves.)

We've been having (in)frequent d-i releases for two release cycles now,
and there have been plenty of chances to determine and implement a “great
compromise”. Several weeks or months after the gradual freeze has started
is way too late by my count.

Hence my current heuristics.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #424 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 846002@bugs.debian.org

Cc: Cyril Brulebois <kibi@debian.org>, Philip Hands <phil@hands.com>, Christian Perrier <bubulle@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 21 Dec 2016 13:23:11 +0100

Hi Holger

On 20.12.2016 15:27, Holger Levsen wrote:
> On Tue, Dec 20, 2016 at 03:16:50PM +0100, Ole Streicher wrote:
>> Again: the installer is there to test for 6 months now, but if it is
>> inacceptably bad: why are there no complaints?
> 
> the complaints have been there for months, you just choose to consider
> them invalid. some people dont like to repeat themselves.

After six months of testing, I would expect that the fears that were
expressed at that times were supported by some real solid experiences.
This is a big difference and in no way a repetition.

Ole

Message #429 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ole Streicher <olebole@debian.org>

Cc: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org, Philip Hands <phil@hands.com>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 21 Dec 2016 10:10:06 -0500

>>>>> "Ole" == Ole Streicher <olebole@debian.org> writes:

    Ole> We already have more that 5700 popcon-counted installations
    Ole> with the blends selection in the installer. This should give
    Ole> some base for that.

Hi.
Speaking with my TC hat on.
I don't find quoting popcon stats useful.  You've used them to support
the claim both that this is important and that users don't find it
confusing.
I understand your reasoning for why you believe that the popcon stats
argue this is not confusing.
I think your reasoning rests of the false assumptions that users are
likely to report bugs when they find something confusing.
In my experience that's not the case.  Instead, they are likely to get
grumpy and decrease their overall confidence in some software.
Users cannot be counted on to proactively report confusing aspects of
software.

I find the claim that this is important because of the popcon numbers
vaguely dubious as well, but it's harder to justify my concern.

At least for me though, every time you quote popcon numbers, I take you
less seriously.

Message #434 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org, Philip Hands <phil@hands.com>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Wed, 21 Dec 2016 16:24:58 +0100

Hi Sam,

On 21.12.2016 16:10, Sam Hartman wrote:
>>>>>> "Ole" == Ole Streicher <olebole@debian.org> writes:
> I don't find quoting popcon stats useful.  You've used them to support
> the claim both that this is important and that users don't find it
> confusing.

I am quoting popcon here since they give a lower estimate of the number
of users who actually did the test. Nothing more. Nothing about importance.

> I think your reasoning rests of the false assumptions that users are
> likely to report bugs when they find something confusing.
> In my experience that's not the case.  Instead, they are likely to get
> grumpy and decrease their overall confidence in some software.
> Users cannot be counted on to proactively report confusing aspects of
> software.

I don't speak about bug reports only. I have searched the net for any
appearance of problems with the blends; also discussion forums and such.

And as I wrote in one of my early statements: there *was* such a case:
in a german forum, someone asked "what does this blends stuff mean?".
This shows that one *gets* a response here. After that response, we
changed the wording; no further complaints were found after that.

And I would also not just count "end user reports". If for example
someone would have done an install party (or such), he would know what
the usual questions of users were. Also if someone recommended to
install Stretch to his friend and had to help somewhere. He could (and
should!) then do a bug report. Didn't happen yet.

"Confusion" is not just something mythical that we can't see empirical.
We will see it in help requests, blog posts, also bug reports, and other
complaints. If the raise of confusion is "inacceptable" as stated here,
I would really ask for some empirical evidence for this. At least, I did
some homework by checking that no complaints popped up somewhere in the
net (except the one I already mentioned).

Best regards

Ole

Message #439 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Cc: Sam Hartman <hartmans@debian.org>, Cyril Brulebois <kibi@debian.org>, Philip Hands <phil@hands.com>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Fri, 23 Dec 2016 10:19:56 +0100

On Wed, 21 Dec 2016, Ole Streicher wrote:
> I am quoting popcon here since they give a lower estimate of the number
> of users who actually did the test. Nothing more. Nothing about importance.

It gives an estimate of users who ran debootstrap and got the package
installed. It does not give an estimate of how many people ran
debian-installer and saw this menu.

> "Confusion" is not just something mythical that we can't see empirical.
> We will see it in help requests, blog posts, also bug reports, and other
> complaints. If the raise of confusion is "inacceptable" as stated here,
> I would really ask for some empirical evidence for this. At least, I did
> some homework by checking that no complaints popped up somewhere in the
> net (except the one I already mentioned).

Except that the persons who are installing a weekly build of testing
are advanced users that are less likely to be confused than the stable
users.

So while I like to be able to refer to real complains and real problem,
in this specific case it's hard to do so except when it's too late.

So I agree with Cyril and the d-i team, we should be cautious here.

Let's focus everybody's energy on getting Phil's patch merged instead
of continuing this discussion.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #444 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Philip Hands <phil@hands.com>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 02:10:26 +0100

[Message part 1 (text/plain, inline)]

Hi,

Philip Hands <phil@hands.com> (2016-12-20):
> Just as a reminder for the upcoming alpha that I was trying to do
> something about this by adding an extra simplified tasksel promt:
> 
> Philip Hands <phil@hands.com> writes:
> ...
> > The menu is now:
> >
> > --> standard ("${DESKTOP}") desktop                           <--
> >     standard server [text-only console & 'ssh' remote access]
> >     other use cases
> 
> I just applied that as a patch to pkgsel and pushed it as pu/simple_tasksel
> 
> It just occurred to me that if we made the list of tasks for each choice
> be in the template, then it avoids hard-wiring the tasks in the code,
> and it should be easier to preseed, so might serve as a customisable menu
> for the likes of debian-edu -- I've added that as a subsequent commit,
> but that's yet to be tested.  I should have time to test that this evening.
> 
> The template needs proper anotation for translators.
> 
> I think it might well be better to replace 'standard' with 'default'.
> 
> BTW as it stands, the server option doesn't bother installing CUPS,
> despite that being in the default tasksel set -- That was based on
> Colin's comment that task-cups needs a rethink, and is currently a bit
> useless.

So I've just looked at the proposed changes, and adding a prompt at this
point is not an option: we're changing logic during the freeze, and
adding translatable material (not the kind of hidden stuff that might
happen with obscure preseeding values, but something that is going to
hit all users) is not a good thing either.

This can be (re)considered during the next release cycle (long before
the freeze if at all possible, this time).


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #449 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Raphael Hertzog <hertzog@debian.org>, 846002@bugs.debian.org, Ole Streicher <olebole@debian.org>

Cc: Sam Hartman <hartmans@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 02:25:48 +0100

[Message part 1 (text/plain, inline)]

Raphael Hertzog <hertzog@debian.org> writes:
...
> So I agree with Cyril and the d-i team, we should be cautious here.
>
> Let's focus everybody's energy on getting Phil's patch merged instead
> of continuing this discussion.

The latest incarnation of which I think is close to ready:

  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel

I've squashed the commits together, so we now have the first (aae3196)
which implements the feature, and would probably be fine as it is (once
comments to the translators have been added as appropriate).

The second commit (1bb1feb) adds a level of indirection in the
template, with code to populate it from some new debconf settings,
which allows one to then customise the menu via preseeding.  This is not
in any way essential to the task in hand, but might well be useful for
others.

I have tested this, with these preseed settings, and it does what one
would hope (adding "Minimal system..." as a third option):

d-i pkgsel/simplified-tasksel/choices string standard ("${DESKTOP}") desktop, standard server [text-only console & 'ssh' remote access], Minimal system (adds no more packages), other use cases
d-i pkgsel/simplified-tasksel/choices-c string ${DESKTOP}-desktop;standard, ssh-server;standard, ;;, ;
d-i pkgsel/simplified-tasksel/longdesc string You can now choose between installing a standard desktop, a standard server, a minimal system, or alternatively to use the task selection menu to have finer grained control over installing tasks and blends.

The use of ; and ;; in the choices-c needs documenting -- ; is being
used as a separator for the tasks to be selected.  A lone ';' is being
used as a marker for the "continue to tasksel" case.  ';;' does not
match that, so converts to selecting no tasks -- I suspect leaving it
blank would work just as well, but have not tried that yet.

If anyone knows how to set choices-c via preseeding, then we might not
need (all of) the second commit.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #454 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Cc: Raphael Hertzog <hertzog@debian.org>, Ole Streicher <olebole@debian.org>, Sam Hartman <hartmans@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 01:58:18 +0000

On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>Raphael Hertzog <hertzog@debian.org> writes:
>...
>> So I agree with Cyril and the d-i team, we should be cautious here.
>>
>> Let's focus everybody's energy on getting Phil's patch merged instead
>> of continuing this discussion.
>
>The latest incarnation of which I think is close to ready:
>
>  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel
>
>I've squashed the commits together, so we now have the first (aae3196)
>which implements the feature, and would probably be fine as it is (once
>comments to the translators have been added as appropriate).
>
>The second commit (1bb1feb) adds a level of indirection in the
>template, with code to populate it from some new debconf settings,
>which allows one to then customise the menu via preseeding.  This is not
>in any way essential to the task in hand, but might well be useful for
>others.

I'll be honest - that code scares me right now. If this was simple,
obvious stuff then I'd be pushing to try and get this in. But it's
not. Comments like

+       # there is no need to do  this twice, and it breaks [back] behaviour if you do

don't help, and I honestly don't understand what

+                       db_subst pkgsel/simplified-tasksel $(echo $i | tr "a-z" "A-Z") "$subst"

is doing when I read the code at 2am. Can you explain this better
please?

To make this kind of change for stretch, we'll also need updates to
translations directly in the installer and in the installation
guide. I'm worried that we're doing this too late in the cycle - as
KiBi says.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier

Message #459 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Steve McIntyre <steve@einval.com>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 09:28:54 +0100

[Message part 1 (text/plain, inline)]

Steve McIntyre <steve@einval.com> writes:

> On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>>Raphael Hertzog <hertzog@debian.org> writes:
>>...
>>> So I agree with Cyril and the d-i team, we should be cautious here.
>>>
>>> Let's focus everybody's energy on getting Phil's patch merged instead
>>> of continuing this discussion.
>>
>>The latest incarnation of which I think is close to ready:
>>
>>  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel
>>
>>I've squashed the commits together, so we now have the first (aae3196)
>>which implements the feature, and would probably be fine as it is (once
>>comments to the translators have been added as appropriate).
>>
>>The second commit (1bb1feb) adds a level of indirection in the
>>template, with code to populate it from some new debconf settings,
>>which allows one to then customise the menu via preseeding.  This is not
>>in any way essential to the task in hand, but might well be useful for
>>others.
>
> I'll be honest - that code scares me right now. If this was simple,
> obvious stuff then I'd be pushing to try and get this in. But it's
> not. Comments like
>
> +       # there is no need to do  this twice, and it breaks [back] behaviour if you do
>
> don't help, and I honestly don't understand what

Fair point, and actually the code that comment applies to is only useful
when 'db_capb backup' is enabled, which for complicated reasons[0] it is
not at present, so I should just comment the lot out to avoid doubt.

> +                       db_subst pkgsel/simplified-tasksel $(echo $i | tr "a-z" "A-Z") "$subst"
>
> is doing when I read the code at 2am. Can you explain this better
> please?

The template that's going to present the question to the user, is this:

=-=-=-=-
Template: pkgsel/simplified-tasksel
Type: select
Choices-C: ${CHOICES-C}
Choices: ${CHOICES}
Description: Choose type of system to install
 ${LONGDESC}
=-=-=-=-

so the loop you're looking at:

=-=-=-=-
for i in choices choices-c longdesc ; do
	db_get pkgsel/simplified-tasksel/$i
	local subst=$(echo $RET | sed "s#[$]{DESKTOP}#$desktop#g")
	db_subst pkgsel/simplified-tasksel $(echo $i | tr "a-z" "A-Z") "$subst"
done
=-=-=-=-

does the following for each of the template variables.

 . Get the preseedable default value using db_get
 . substitute any occurrences of ${DESKTOP} with the current value of
   $desktop (so gnome unless you preseeded a different desktop)
 . do the actual substitution, which currently needs the variable name to
   be uppercased

I could make that rather simpler by naming the preseedable defaults with
uppercase names (e.g. pkgsel/simplified-tasksel/CHOICES) and uppercasing
everywhere, which would eliminate the need to do the tr.

Alternatively one could use lowercase variables in the template to get
the same effect (I didn't do that, to avoid confusing translators who
will be used to upper-case)

Anyway, it's far from clear that this code is needed, and if the extra
complication is a barrier, let's forget the preseedability aspect, and
simply concentrate on the first patch.

> To make this kind of change for stretch, we'll also need updates to
> translations directly in the installer and in the installation
> guide. I'm worried that we're doing this too late in the cycle - as
> KiBi says.

I agree.  This is the wrong time to be doing this.  If I'd had time
earlier in the cycle, I might well have done something about it then,
but ... kids, basically ;-)

Given that we're starting from where we're at, we seem to have a choice
of either adding translatable strings at this late stage, or dumping the
blends for another cycle -- neither option is perfect.

I happen to think that what I've knocked up results in a better user
experience, but then I never liked tasksel and almost never use the
defaults it presents, so I'm not really the target audience for this.

Cheers, Phil.

[0] I was trying to make it so that tasksel would have a [BACK] button,
and one could thus go:

  Oh, I wonder what "other use cases" means ...

  Argh! My eyes!

  [BACK]

  Phew! That's better, I'll have a Desktop in that case.

If you do that, and you allow the db_subst bit to be executed a second
time, it breaks, hence the:

  if [ -z "$desk_subst" ] ; then
     ...
     desk_subst=true

code.

However this all turns out to be irrelevant because the 'db_go' in here:

  https://anonscm.debian.org/cgit/tasksel/tasksel.git/tree/tasksel-debconf

where is says "intentionally unguarded" and _should_ cause the script to
abort (because of set -e) with an error code of 30 if one selects
"BACK", doesn't.

It always returns 0, regardless.

So you never find out that the user wanted to go back.

I presume this is a bug in debconf somewhere, but none of the related
code seems to have changed since Joey wrote it, and back buttons work
elsewhere, so this is quite puzzling.

To avoid the problem I got rid of the 'db_capb backup' so we don't have
back buttons anyway -- I should just comment out the related code for
now, with a comment about the breakage in tasksel/db_go, so that it
might get fixed in future without someone (me probably) having to go
through all the same diagnosis to track down what's wrong.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #464 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Steve McIntyre <steve@einval.com>, 846002@bugs.debian.org

Cc: Raphael Hertzog <hertzog@debian.org>, Ole Streicher <olebole@debian.org>, Sam Hartman <hartmans@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 10:21:44 +0100

[Message part 1 (text/plain, inline)]

Philip Hands <phil@hands.com> writes:

> Steve McIntyre <steve@einval.com> writes:
>
>> On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>>>Raphael Hertzog <hertzog@debian.org> writes:
>>>...
>>>> So I agree with Cyril and the d-i team, we should be cautious here.
>>>>
>>>> Let's focus everybody's energy on getting Phil's patch merged instead
>>>> of continuing this discussion.
>>>
>>>The latest incarnation of which I think is close to ready:
>>>
>>>  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel
>>>
>>>I've squashed the commits together, so we now have the first (aae3196)
>>>which implements the feature, and would probably be fine as it is (once
>>>comments to the translators have been added as appropriate).
>>>
>>>The second commit (1bb1feb) adds a level of indirection in the
>>>template, with code to populate it from some new debconf settings,
>>>which allows one to then customise the menu via preseeding.  This is not
>>>in any way essential to the task in hand, but might well be useful for
>>>others.
>>
>> I'll be honest - that code scares me right now. If this was simple,
>> obvious stuff then I'd be pushing to try and get this in. But it's
>> not. Comments like
>>
>> +       # there is no need to do  this twice, and it breaks [back] behaviour if you do
>>
>> don't help, and I honestly don't understand what
>
> Fair point, and actually the code that comment applies to is only useful
> when 'db_capb backup' is enabled, which for complicated reasons[0] it is
> not at present, so I should just comment the lot out to avoid doubt.

So, for simplicity, we should just consider this version:

  https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel2

I've left the fixup separate to make it easy to see that I've really
just removed the redundant if, and added some more verbose comments.

The commits in this branch should be squashed together if they ever get
into master.

The resulting code is here:

  https://anonscm.debian.org/cgit/d-i/pkgsel.git/tree/debian/postinst?h=pu/simple_tasksel2&id=3739e72f563f86a4a2cf539361c791520b96fa86#n49

HTH

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #469 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org

Cc: Philip Hands <phil@hands.com>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 20:31:52 +0100

On Sat, 24 Dec 2016, Cyril Brulebois wrote:
> So I've just looked at the proposed changes, and adding a prompt at this
> point is not an option: we're changing logic during the freeze, and
> adding translatable material (not the kind of hidden stuff that might
> happen with obscure preseeding values, but something that is going to
> hit all users) is not a good thing either.

I would suggest to commit this to git, do a call for translators to update
this new translation and then judge on the result to see if you have enough
translations to release it for stretch.

I know it's late in the release cycle, but we're not yet in deep freeze
and the release team has always accomodated far more invasive changes to
debian-installer in the past.

But a plain reject at this point with the associated refusal for the blends to
appear in the list is going to make everybody upset which is a pity since
we have a rather good compromise here.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #474 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Raphael Hertzog <hertzog@debian.org>

Cc: 846002@bugs.debian.org, Philip Hands <phil@hands.com>

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 22:24:27 +0100

[Message part 1 (text/plain, inline)]

Raphael Hertzog <hertzog@debian.org> (2016-12-24):
> I would suggest to commit this to git, do a call for translators to
> update this new translation and then judge on the result to see if you
> have enough translations to release it for stretch.
> 
> I know it's late in the release cycle, but we're not yet in deep
> freeze and the release team has always accomodated far more invasive
> changes to debian-installer in the past.

I've already explained why this wasn't a reasonable approach in earlier
mails over the past few days. I'm fine with asking the release team to
accomodate for changes which are needed, but those don't qualify. Heck,
we had obvious syntax issues in bash scripts in earlier commits, plenty
of question marks, and even Steve didn't understand the resulting code
when trying to get me to rethink my decision a few hours ago.

> But a plain reject at this point with the associated refusal for the
> blends to appear in the list is going to make everybody upset which is
> a pity since we have a rather good compromise here.

The real pity here is that nobody addressed my early comments when there
was plenty of time. Like early this year, plenty of months ago.

See you next release cycle. The earlier, the better.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #479 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 22:43:20 +0100

[Message part 1 (text/plain, inline)]

Cyril Brulebois <kibi@debian.org> writes:

> Raphael Hertzog <hertzog@debian.org> (2016-12-24):
>> I would suggest to commit this to git, do a call for translators to
>> update this new translation and then judge on the result to see if you
>> have enough translations to release it for stretch.
>> 
>> I know it's late in the release cycle, but we're not yet in deep
>> freeze and the release team has always accomodated far more invasive
>> changes to debian-installer in the past.
>
> I've already explained why this wasn't a reasonable approach in earlier
> mails over the past few days. I'm fine with asking the release team to
> accomodate for changes which are needed, but those don't qualify. Heck,
> we had obvious syntax issues in bash scripts in earlier commits, plenty
> of question marks

OK, this is tiresome -- you're complaining about question marks when I
was still exploring the options and looking for feedback -- I could
instead have been definite about an earlier option, but that would have
deprived you of choices, and would not have resulted in a patch as good
as it is now.

Please don't punish me for being open about my feelings on the various
commits because if you do that you'll reap the whirlwind when people
start lying to you to get past your superficial metrics.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #484 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Philip Hands <phil@hands.com>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sat, 24 Dec 2016 23:10:33 +0100

[Message part 1 (text/plain, inline)]

Philip Hands <phil@hands.com> (2016-12-24):
> OK, this is tiresome -- you're complaining about question marks when I
> was still exploring the options and looking for feedback -- I could
> instead have been definite about an earlier option, but that would
> have deprived you of choices, and would not have resulted in a patch
> as good as it is now.
> 
> Please don't punish me for being open about my feelings on the various
> commits because if you do that you'll reap the whirlwind when people
> start lying to you to get past your superficial metrics.

My initial comments weren't about those. But they indeed add up with
what I mentioned earlier, and this tends to confirm that december,
with a freeze already started, is just not the right time to start
exploring options.

Sorry, but my mind is made up here: it's just too late (1) to change
tasksel entirely, (2) to require translation updates we're already not
getting in time, be it for screens, and for the installation guide.

I'll stop repeating myself here, and start enjoying festivities.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #489 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Date: Sun, 25 Dec 2016 19:00:39 +0100

[Message part 1 (text/plain, inline)]

Cyril Brulebois <kibi@debian.org> writes:

> Philip Hands <phil@hands.com> (2016-12-24):
>> OK, this is tiresome -- you're complaining about question marks when I
>> was still exploring the options and looking for feedback -- I could
>> instead have been definite about an earlier option, but that would
>> have deprived you of choices, and would not have resulted in a patch
>> as good as it is now.
>> 
>> Please don't punish me for being open about my feelings on the various
>> commits because if you do that you'll reap the whirlwind when people
>> start lying to you to get past your superficial metrics.
>
> My initial comments weren't about those.

I've no idea what you mean by that sentence really, but it's possible
that it renders the rest of this mail totally irrelevant, so feel free
to clarify in that case.

> But they indeed add up with
> what I mentioned earlier, and this tends to confirm that december,
> with a freeze already started, is just not the right time to start
> exploring options.
>
> Sorry, but my mind is made up here: it's just too late (1) to change
> tasksel entirely, (2) to require translation updates we're already not
> getting in time, be it for screens, and for the installation guide.
>
> I'll stop repeating myself here, and start enjoying festivities.

Just in case there was any doubt, I have no problem with the decision
that this is all too late -- it was clear that might well be the outcome
when I started this, so I'm not surprised.

I was just concerned that you might be basing that decision on some
false perceptions.

Now that I've had chance to check, it seems that there was just one
commit with a question mark in the commit message:

  "move the task lists into the template (to make it preseedable?)"
  http://deb.li/3maqd

which was only there to remind me to check if I could find a way of
preseeding the Choices-C: value (seems not, BTW).

It also happens to be the commit where the '; then' was missing (which I
guess would be the obvious syntax errors you mention).

Perhaps you saw that commit being present from 09:28 on Dec 20th and
only being fixed at 22:07 on Dec 22nd and thought I was being totally
rubbish.

In fact, the reason I pushed that on the morning of the 20th was because
I knew I was going to be busy all day and wanted jenkins to also be busy
testing for me while I was out.

Of course, when I came back, I discovered that by then d-i FTBFS because
of the dejavu rename, so then I spent some time fixing that (leaving the
broken commit in place even longer).

So, if you are judging this negatively on the basis of that commit, then
you are failing to understand that the reason you saw that commit was
because I was attempting to get jenkins to do some testing for me while
I didn't have time to do it myself -- which is rather the point of
jenkins.

The reason it stayed there so long unfixed with its question mark was
because of the dejavu rename FTBFS.

I do not point this out in an attempt to change your decision in this
particular case, but rather to point out that it makes little sense to
be overly judgemental about such a commit.

The reason I've been putting effort into jenkins is so that people
(myself in particular) should be able to throw commits at jenkins and
have them tested without worrying too much about whether they are
perfect.  The hope being that this would lower the bar for contributions
by letting people play in safety while getting decent feedback about
whether their efforts were producing viable results.

Frowning at people when they then use that system for its designed
purpose seems just a tad counter productive.

Anyway, no hard feelings, and I hope you're having fun :-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #494 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Margarita Manterola <marga@debian.org>

To: 846002@bugs.debian.org

Subject: blends-tasks must not be priority:important - ballot proposal

Date: Mon, 26 Dec 2016 10:43:04 -0300

Hi,

I was supposed to do this last week, but Christmas got in the way.  Apologies
for the delay.

While it's great that there is a possibly better solution in the works for the
tasksel screen, there's still the issue at hand that blends-tasks has used the
severity of the package as a way of circumventing collaboration with tasksel
maintainers.

I believe the TC should rule on this issue and I propose the following ballot:

====================
A: The blends-tasks package should be dropped and its contents integrated into
tasksel.
Z: Further discussion
====================

Additionally, we should strongly encourage the maintainers of both tasksel and
blends-tasks to collaborate and decide on a timeline for the needed changes.  In
particular, we would leave the decision as to whether to do this before or after
the Strech release to the involved parties.

The reason why I believe it's important that we rule (even if a better tasksel
screen is in the works) is that I don't think it's ok for a maintainer to use
package priorities (or other similar abuse of technical measures) to avoid
collaborating with other teams. While I understand that d-i is in dear need of
peoplepower, this is still not a reason for going around them, it would instead
be a reason to try to volunteer some work for them.

We could also have options regarding whether this should be implemented for
Stretch or not, but given our discussion on IRC last week, I got the feeling
that we wanted to leave this to the involved parties.  If someone feels strongly
that we should have options for that, we can add them (the same for having an
explicit "blends-tasks can stay with priority important" option).

My vote for the above mentioned ballot, then:
A > Z

-- 
Regards,
Marga

Message #499 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Margarita Manterola <marga@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important - ballot proposal

Date: Mon, 26 Dec 2016 15:16:27 +0100

Hi Margarita,

On 26.12.2016 14:43, Margarita Manterola wrote:
> While it's great that there is a possibly better solution in the works for the
> tasksel screen, there's still the issue at hand that blends-tasks has used the
> severity of the package as a way of circumventing collaboration with tasksel
> maintainers.

I already several times pointed that out: We did not "circumvent" the
collaboration with the tasksel maintainers.

The relevant bug #758116 was assigned to tasksel for quite a long time,
and the proposed solution to create a package blends-tasks was announced
exactly there -- so the proposal was on the desk of the tasksel
maintainers, explicitly asking if they would veto.

The first response from a tasksel maintainer came only five weeks later,
without a veto, but with a discussion that finally lead to the current
wording and selection. This is not what I would usually call "circumvent
collaboration".

For any other critics, the usual way to collaborate is to open a bug
report. This did not happen then before of this bug (#846002). #846002
was again based on the first version of blends-tasks (see Holgers
initial message), and he failed to rebase it within an reasonable time
(and the original critics were already handled by the update to
blends-tasks 0.6.94 as described above).

And, again, IMO the d-i team several times expressed their heavy
overload. It seems natural that working on the blends selection in
tasksel or the correct wording should be done by the people who actually
deal with the blends, avoiding to put additional load on them.

Could you support your accusation a bit? I have the feeling that you are
ignoring my arguments (since I have put them here already).

Best regards

Ole

Message #504 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Margarita Manterola <marga@debian.org>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important - ballot proposal

Date: Mon, 26 Dec 2016 13:26:52 -0300

[Message part 1 (text/plain, inline)]

Hola Ole Streicher!

First let me start by saying that I'm sorry that you felt accused.  It was not
my intention to turn this into some kind of finger pointing, and I'm genuinely
sorry of my choice of language, as it clearly wasn't good enough to show that.

Let me assure you that the only thing I want is to improve collaboration between
teams, with the assumption that everyone involved wants what's best for Debian,
even if sometimes it's hard to agree upon the details.

> I already several times pointed that out: We did not "circumvent" the
> collaboration with the tasksel maintainers.

I understand that it was not your intention and that you acted in good faith.
Please believe me when I say this.  As human beings, sometimes we mean well but
still make mistakes. The important point is to correct those mistakes and move
on.

> The relevant bug #758116 was assigned to tasksel for quite a long time,
> and the proposed solution to create a package blends-tasks was announced
> exactly there -- so the proposal was on the desk of the tasksel
> maintainers, explicitly asking if they would veto.

A short re-cap of that bug:

14 Aug 2014 to 3 Nov 2014: a long discussion involving quite a number of people
regarding whether or not to include blends in the installer, discussing which
blends to include, how to choose, etc. This died out with no action.

4 Nov 2015: a ping from you stating that you'd like to move on with this,
followed by replies from KiBi & Andreas.

3 Apr 2016: a message from you stating your idea of the blends-task package,
asking whether this would be vetoed or not. Silence.  The package gets uploaded
on 11 Apr 2016. i.e. 8 days after the question was made.

17 May 2016: KiBi makes a number of comments related to the end result and how
he's not too happy about this. This leads to some discussion where basically the
d-i people state that they are not happy with the implementation at the time,
which leads to some wording improvements.

21 May 2016: KiBi notices how blends-tasks managed to get displayed in the
intaller through using the severity: important field, and how he's not happy
about this. Followed by some discussion that eventually dies out.

> The first response from a tasksel maintainer came only five weeks later,
> without a veto, but with a discussion that finally lead to the current
> wording and selection. This is not what I would usually call "circumvent
> collaboration".

Clearly, we know already that KiBi is overloaded and can't always reply to
emails within a week. Replying 5 weeks afterwards is not something that I fault
him for. Particularly for a bug that was 1.5 years old.

I understand that sometimes it might be better to get things done and then
incorporate feedback as it comes instead of waiting for feedback until doing
anything. This is generally ok if you are confident enough on your chosen
solution.

The problem with the above mentioned timeline is that when his concern was
voiced regarding the way the items were added to the installer, this led to no
action.  And at no point a patch for tasksel was provided.

> And, again, IMO the d-i team several times expressed their heavy
> overload. It seems natural that working on the blends selection in
> tasksel or the correct wording should be done by the people who actually
> deal with the blends, avoiding to put additional load on them.

Yes.  But this does not mean that it should be done in a separate package.

Adding items to the default installer (as opposed to a separate installer that
includes additional udebs) should be done by adding those lines in tasksel, in
agreement with the d-i maintainers.

The fact that they are overloaded doesn't mean that they won't take a patch if
you provide one.

Again, please let me assure you that my only goal here is to improve
collaboration.  The ideal outcome of this issue for me would be that the new
items get added to tasksel through an agreement between the involved parties and
we can all move on to keep improving Debian.

I apologise again for my choice of language in the previous mail. I hope my
point is clearer now.

Thanks.

-- 
Regards,
Marga

[signature.asc (application/pgp-signature, inline)]

Message #509 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Margarita Manterola <marga@debian.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important - ballot proposal

Date: Mon, 26 Dec 2016 22:02:03 -0300

> I believe the TC should rule on this issue and I propose the following ballot:
> ====================
> A: The blends-tasks package should be dropped and its contents integrated into
> tasksel.
> Z: Further discussion
> ====================
> (...)
> My vote for the above mentioned ballot, then:
> A > Z

It has been brought to my attention that this was mixing the discussion and the
voting period. Please consider this a starter for the discussion period of this
ballot. Once people voiced their opinion we may call for a proper vote.

Thanks.

-- 
Marga

Message #514 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Margarita Manterola <marga@debian.org>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must not be priority:important - ballot proposal

Date: Tue, 27 Dec 2016 19:25:32 -0500

Is our intent to override the maintainer or provide advice?
I don't care what the answer is but perhaps we want to be clear.
I'm fine with this ballot beyond that.
Perhaps we want to override the blends-tasks maintainers to the extent
that they disagree with the tasksel maintainers?

Message #519 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tille@debian.org>

To: Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org

Cc: Margarita Manterola <marga@debian.org>

Subject: Re: Bug#846002: blends-tasks must not be priority:important - ballot proposal

Date: Mon, 9 Jan 2017 09:38:16 +0100

Hi all,

On Tue, Dec 27, 2016 at 07:25:32PM -0500, Sam Hartman wrote:
> Is our intent to override the maintainer or provide advice?
> I don't care what the answer is but perhaps we want to be clear.
> I'm fine with this ballot beyond that.
> Perhaps we want to override the blends-tasks maintainers to the extent
> that they disagree with the tasksel maintainers?

Past Christmas I was quite occupied by real life (and my sweet family
;-) members) but just a short note:  I think the Blends team is really
happy if a Blends selection will happen at the tasksel step - no matter
how it is finally implemented.

Kind regards and happy new year

      Andreas.

-- 
http://fam-tille.de

Message #524 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: debian-boot@lists.debian.org, debian-devel-announce@lists.debian.org, 846002@bugs.debian.org

Subject: Re: Debian Installer Stretch RC 1 release

Date: Sun, 15 Jan 2017 14:24:13 +0100

On 15.01.2017 05:21, Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the first release
> candidate of the installer for Debian 9 "Stretch".
> 
> 
> Important changes in this release of the installer
> ==================================================
> 
>  * [...]
>  * As noted in the Stretch Alpha 6 release announcement, Debian Pure
>    Blends appeared in the Software selection screen. Unfortunately,
>    concerns voiced back then weren't worked on until after the freeze
>    started, and a freeze isn't the time where critical screens should
>    be revamped. Support was disabled accordingly.

Since this is still an open discussion in #846002, I would have
preferred if you would not try to force your own preference here before
the CTTE made its decision. IMO your solution is not in any way
cooperative and tries to make the CTTE decision useless.

I therefore would ask the CTTE to make a final decision about the
inclusion of the blends selection in the Stretch installer. In principle
these are *two* decisions:

1. Appearance of the blends in the installer:

Please decide, whether

 * the blends shall be shown in their current (alpha-8) form

 * The installer is extended to show the desktop and the blends only
   optionally (as propagated by Phil, and opposed by Cyril)

 * the blends should not appear in the Stretch installer at all.

2. Maintenance of the blends tasks appearing in the installer:

 * in a separate package maintained by the blends team

 * integrated into tasksel and maintained by d-i

 * be removed completely from the installation process

Best regards

Ole

Message #531 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: 846002@bugs.debian.org, Cyril Brulebois <kibi@debian.org>

Subject: Re: Debian Installer Stretch RC 1 release

Date: Mon, 16 Jan 2017 10:01:19 +0100

Cyril Brulebois <kibi@debian.org>
> The real pity here is that nobody addressed my early comments when there
> was plenty of time. Like early this year, plenty of months ago.

This is not true. What we did is improving the wording, and limiting the
number of blends. There was no response from you after that for all the
time.

> Having more choices means more confusion. Look at any UX studies, or
> install parties.

If you would really care about confusion, why did you add LXQt to the
desktop tasks in October 2016 (4cebe1da, 3.38)? Do you really think that
this acronym will confuse people less than "Special tasks for ...
astronomers"? What is the rationale for allowing that, bug removing the
blends?

To me, this looks like that you just have personal preference in what
should be there (and what not) and use the confusion as a
pseudo-argument to support your preference.

Best regards

Ole

Message #536 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tille@debian.org>

To: 846002@bugs.debian.org

Cc: debian-boot@lists.debian.org, Debian Developers <debian-devel@lists.debian.org>

Subject: Re: Bug#846002: Debian Installer Stretch RC 1 release

Date: Tue, 17 Jan 2017 09:02:09 +0100

Hi,

On Sun, Jan 15, 2017 at 02:24:13PM +0100, Ole Streicher wrote:
> > Important changes in this release of the installer
> > ==================================================
> > 
> >  * [...]
> >  * As noted in the Stretch Alpha 6 release announcement, Debian Pure
> >    Blends appeared in the Software selection screen. Unfortunately,
> >    concerns voiced back then weren't worked on until after the freeze
> >    started, and a freeze isn't the time where critical screens should
> >    be revamped. Support was disabled accordingly.
> 
> Since this is still an open discussion in #846002, I would have
> preferred if you would not try to force your own preference here before
> the CTTE made its decision.

While I'm not sure whether its a personal preference or whether some
discussion I might have missed has lead to this result but I'm similar
astonished as Ole about this result without a final decision of the
CTTE.

Kind regards and thanks for working on the installer in any case

      Andreas. 

-- 
http://fam-tille.de

Message #541 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Bjørn Mork <bjorn@mork.no>

To: Andreas Tille <tille@debian.org>

Cc: 846002@bugs.debian.org, debian-boot@lists.debian.org, Debian Developers <debian-devel@lists.debian.org>

Subject: Re: Bug#846002: Debian Installer Stretch RC 1 release

Date: Tue, 17 Jan 2017 10:28:50 +0100

Andreas Tille <tille@debian.org> writes:

>> Since this is still an open discussion in #846002, I would have
>> preferred if you would not try to force your own preference here before
>> the CTTE made its decision.
>
> While I'm not sure whether its a personal preference or whether some
> discussion I might have missed has lead to this result but I'm similar
> astonished as Ole about this result without a final decision of the
> CTTE.

If I can offer an view from the outside of this discussion:

To me it looks like a sandbox fight which started with the creative use
of "Priority: important". Now it appears that the party starting the
fight thinks the other party should stop throwing sand until "mommy"
(aka CTTE) decides who is right and who is wrong.

I have of course probably gotten all this wrong.  But that doesn't
really matter.  The above describes how *I* subjectively perceive the
situation.  That is not a subject for discussion.

My personal advice, since I'm out here providing opionions nobody asked
for anyway, would be to start co-operating with the tasksel/installer
developers instead of waiting for a CTTE decision.  That's not going to
solve your issues anyway.

Because, as has been pointed out by several people already: This whole
mess was pointless from the start. No new Debian user will ever
understand the meaning of the task menu.  And no experienced Debian user
will use it.  Adding anything there is futile.  You need to get into a
dialogue with the installer developers so that you can find a way to
properly integrate blends.  And possibly remove tasks.

This is of course way too late for Stretch.  Live with it. Or continue
wasting everybodys time on pointless discussions and be too late for the
next release as well....


Bjørn

Message #546 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Bjørn Mork <bjorn@mork.no>, 846002@bugs.debian.org, Andreas Tille <tille@debian.org>

Cc: debian-boot@lists.debian.org, Debian Developers <debian-devel@lists.debian.org>

Subject: Re: Bug#846002: Debian Installer Stretch RC 1 release

Date: Tue, 17 Jan 2017 11:58:58 +0100

Hi Bjørn,

Am 17.01.2017 um 10:28 schrieb Bjørn Mork:
> To me it looks like a sandbox fight which started with the creative use
> of "Priority: important". Now it appears that the party starting the
> fight thinks the other party should stop throwing sand until "mommy"
> (aka CTTE) decides who is right and who is wrong.
> 
> I have of course probably gotten all this wrong.  But that doesn't
> really matter.  The above describes how *I* subjectively perceive the
> situation.  That is not a subject for discussion.
> 
> My personal advice, since I'm out here providing opionions nobody asked
> for anyway, would be to start co-operating with the tasksel/installer
> developers instead of waiting for a CTTE decision.  That's not going to
> solve your issues anyway.

I think that your impression is not true here: "Priority: important" is
the usual way to get a package installed at install time. And we
announced to do this in the relevant bug, and this reached the table of
d-i, with an explicite request for a comment or veto (which did not happen).

After the following discussion we limited the number of entries and
changed the wording to be less confusing. There was no response or
critics to this from d-i until #846002 was opened (which was too late
for other changes, according to Cyril). We were always ready to
co-operate here, but without a getting a response this is a bit difficult.

In the meantime, tasksel was extended by another entry "LXQt", making
the "we don't want add items as they increase the confusion of tasksel"
argument questionable.

BTW, the usual way to cooperate is to open a bug report if something
seems to go the wrong way with a package. If d-i was so unhappy about
blends-tasks, why didn' they open a bug in summer saying that wording
change and limiting entries is not enough?

Finally: Yes, it seems that we have a conflict between two teams (blends
and d-i), and CTTE is asked to decide for the technically best solution.
I would really ask CTTE to evaluate the "confusion" argument (which is
the central one here) in order to make a decision whether the blends
should go into the installation menu or not. And who should maintain it
(the blends or the d-i team) -- these two were the questions raised in
the beginning from Holger.

Best regards

Ole

Message #551 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Gonzalo Cevallos <gonzalocevallos34@gmail.com>

To: Bjørn Mork <bjorn@mork.no>

Cc: Debian Developers <debian-devel@lists.debian.org>, debian-boot@lists.debian.org, 846002@bugs.debian.org, Andreas Tille <tille@debian.org>

Subject: Re: Congratulation:gonzalo_Eligibility for Fresh Start Tax Program tTMr198.9.78.72.9.148.37221.123.0.5tTMr

Date: Tue, 17 Jan 2017 13:41:06 -0500

[Message part 1 (text/plain, inline)]

What

On Jan 17, 2017 1:40 PM, "Bjørn Mork" <bjorn@mork.no> wrote:

> dfhg
>
> gonzalo_Qualify_for_Tax_Debt_ Relief?
>
> Check_Your_Eligibility
>
>
>
>
> <http://unige.ch/biblio/plus/ressources/rep_redirect.php?nom=The+World+Atlas+of+Language+Structures+Online&url=http%3A%2F%2Furlurl.link/gO3f6>
> <http://unige.ch/biblio/plus/ressources/rep_redirect.php?nom=The+World+Atlas+of+Language+Structures+Online&url=http%3A%2F%2Furlurl.link/pIp0d>
> <http://unige.ch/biblio/plus/ressources/rep_redirect.php?nom=The+World+Atlas+of+Language+Structures+Online&url=http%3A%2F%2Furlurl.link/Ix7dT>
> asdf
> asdf
> asdf
>
>

[Message part 2 (text/html, inline)]

Message #556 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: 846002@bugs.debian.org

Cc: Margarita Manterola <marga@debian.org>

Subject: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Mon, 30 Jan 2017 16:43:57 +0100

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

Message #561 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ole Streicher <olebole@debian.org>

Cc: 846002@bugs.debian.org, Margarita Manterola <marga@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Tue, 31 Jan 2017 10:26:45 -0500

>>>>> "Ole" == Ole Streicher <olebole@debian.org> writes:


Hi.
If you go back one meeting further, my interpretation is that the consensus of
the committee seems to be that ultimately this decision belongs to the
installer team.
That is, in this case, a number of members on the TC seem to believe
that the installer team gets to decide whether/how the installer makes
it easy to install blends.
If they don't want to do that for stretch, that's a decision within
their pervue that we clearly don't have the votes to override.
(It's not clear we have any support on the TC for overriding for stretch
at all).

I understand that's not the answer you want to hear.
Also, it's only my interpretation: that's not a vote of the TC.
I also agree that it's unfortunate that we were slow enough we failed to
give that answer then.  I'm part of being slow in that regard: while I
supported the ballot that was put forward, I did not indicate my support
in a manner where the proponent saw it, and partially as a result, no
vote was called.

I suspect that if things can't be resolved fairly early in the buster
cycle, the TC would be much more willing to get more hands-on here.  I
know I would.

Message #566 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org

Cc: Margarita Manterola <marga@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Tue, 31 Jan 2017 17:28:09 +0100

Hi Sam,

Am 31.01.2017 um 16:26 schrieb Sam Hartman:
> If you go back one meeting further, my interpretation is that the consensus of
> the committee seems to be that ultimately this decision belongs to the
> installer team.
> That is, in this case, a number of members on the TC seem to believe
> that the installer team gets to decide whether/how the installer makes
> it easy to install blends.
> If they don't want to do that for stretch, that's a decision within
> their pervue that we clearly don't have the votes to override.

Hmm, IMO there are two things here: First, in our constitution, the
installer team has no specific granted rights, apart from being
maintainers of the relevant packages. This makes the conflict primarily
a conflict between developers having different opinions about how to
solve a certain problem. A decision here falls under the rights
granted to the Technical Team by the Project leader. And I would expect
that a decision would be made on some technical foundation.

Second, I would expect a bit more moderation. A major part of the
discussion here was still covering either the question whether it is
policy conform/useful/hijacking to add something to the installer
tasksel menu by making the package priority "important", or by
discussing the (rejected then by d-i) compromise solution with an
additional selection.

What was however *missing* is a discussion of whether the menu in its
current form may be a compromise -- the original bug report was based on
an outdated version. Holger, the original author of the bug stated (#144):

Holger Levsen <holger@layer-acht.org>
> indeed, this is what it looks today. Just verified myself too.
> 
> And this *is* still pretty confusing, though admitly better than it was
> half a year ago. 

We all agree here that the menu is confusing, and that the Blends
entries don't make it better. The primary question here is however: does
it really make it so much worse that we can't include it in Stretch?
Compared to the LXQt menu entry addition? At least I doubt that (not
surprisingly), and I tried to put my arguments here.

When we had the first version, one of the main arguments was that the
people would get confused by entries that they don't understand (the
items were just the Blends names then). We took this serious and changed
them to well-understandable names. What makes the "Blends" section in
tasksel IMO more understandable than the "Desktop environment" section
(What the heck is Mate? And what is the difference between LXDE and
LXQt? I myself must google to find that out!) We also limited the
entries to the blends for which the menu would be really useful, which
covers the "too much entries" argument. In the moment, I don't see a
real other argument; however Cyril stated that his remarks were not
adressed. They were. He then just didn't make further comments.

And this is what I just don't take; I expect some technical discussion,
and if we can't come to a compromise ourself, than we need some
moderation (and, if nothing helps, a decision) from the Technical
Commitee. This is at least how I read
<https://www.debian.org/devel/tech-ctte>. It is *not* about just "hey,
d-i decided that way. Sorry, we can't do anything here". It is about to
help us (d-blends and d-i) to sort out the technical aspects, to weight
them and to come to a solution where everyone can agree as much as possible.

Best regards

Ole

Message #571 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ole Streicher <olebole@debian.org>

Cc: 846002@bugs.debian.org, Margarita Manterola <marga@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Tue, 31 Jan 2017 15:45:09 -0500

>>>>> "Ole" == Ole Streicher <olebole@debian.org> writes:

    Ole> Hi Sam, Am 31.01.2017 um 16:26 schrieb Sam Hartman:
    >> If you go back one meeting further, my interpretation is that the
    >> consensus of the committee seems to be that ultimately this
    >> decision belongs to the installer team.  That is, in this case, a
    >> number of members on the TC seem to believe that the installer
    >> team gets to decide whether/how the installer makes it easy to
    >> install blends.  If they don't want to do that for stretch,
    >> that's a decision within their pervue that we clearly don't have
    >> the votes to override.

    Ole> Hmm, IMO there are two things here: First, in our constitution,
    Ole> the installer team has no specific granted rights, apart from
    Ole> being maintainers of the relevant packages. This makes the
    Ole> conflict primarily a conflict between developers having
    Ole> different opinions about how to solve a certain problem. A
    Ole> decision here falls under the rights granted to the Technical
    Ole> Team by the Project leader.

I think you mean by the constitution.
I could see that argument.

    Ole> And I would expect that a decision
    Ole> would be made on some technical foundation.

A lot of people expect that.
A lot of what the TC does involves understanding how to balance
technical and non-technical factors.
It seems entirely appropriate for the TC to look at the technical issues
here and decide who should be making the decision rather than to make a
decision.

What I think several of us did is look at the technical details and
decide we believe that the installer team was the right set of people to
make this technical decision.

So, I think the TC will make its decisions on a technical foundation a
lot less frequently than you do.
That said, I do think an understanding of which technical factors are
important is something we need to do.

If there are things I can to to help you believe that we did consider
the points you think important I'd like to do that.  If you can think of
things I can do to help you gain confidence that we have heard you,
please let me know.

That said, I'm hoping you can respect me when I say that hearing you
does not mean agreeing with you--not even about what factors are
important in making a decision.

--Sam

Message #576 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Joerg Jaspert <joerg@debian.org>

To: Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>, Margarita Manterola <marga@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Wed, 01 Feb 2017 14:29:20 +0800

Am 2017-02-01 04:45, schrieb Sam Hartman:

> What I think several of us did is look at the technical details and
> decide we believe that the installer team was the right set of people 
> to
> make this technical decision.

> So, I think the TC will make its decisions on a technical foundation a
> lot less frequently than you do.
> That said, I do think an understanding of which technical factors are
> important is something we need to do.

> If there are things I can to to help you believe that we did consider
> the points you think important I'd like to do that.  If you can think 
> of
> things I can do to help you gain confidence that we have heard you,
> please let me know.

> That said, I'm hoping you can respect me when I say that hearing you
> does not mean agreeing with you--not even about what factors are
> important in making a decision.

You got asked as TC to decide which way it should go. Right now you try 
to shy out of giving an answer
to that. Instead you should just decide on it, and if you all think its 
the installers team to decide
and Ole lost, then issue such a statement. Everything else is just 
another plain fail.

-- 
bye Joerg

Message #581 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org

Cc: Margarita Manterola <marga@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Wed, 1 Feb 2017 13:23:50 +0100

Hi Sam,

Am 31.01.2017 um 21:45 schrieb Sam Hartman:
> Ole> Hmm, IMO there are two things here: First, in our constitution, 
> Ole> the installer team has no specific granted rights, apart from 
> Ole> being maintainers of the relevant packages. This makes the Ole>
> conflict primarily a conflict between developers having Ole>
> different opinions about how to solve a certain problem. A Ole>
> decision here falls under the rights granted to the Technical Ole>
> Team by the Project leader.
> 
> I think you mean by the constitution.

Yes.

> I could see that argument.

> 
> Ole> And I would expect that a decision Ole> would be made on some
> technical foundation.
> 
> A lot of people expect that. A lot of what the TC does involves
> understanding how to balance technical and non-technical factors. It
> seems entirely appropriate for the TC to look at the technical
> issues here and decide who should be making the decision rather than
> to make a decision.
> 
> What I think several of us did is look at the technical details and 
> decide we believe that the installer team was the right set of people
> to make this technical decision.

I must say that I find your behaviour a bit opaque here, which is (as
far as I understand it) is not the goal of the TC. The idea is not to
just have a court which just releases its final (no-)decision, but to
sort out technical arguments for a final decision. This is at least how
I read your docs [1]. If this is not the case, maybe they should be
adjusted to be not misleading here.

> So, I think the TC will make its decisions on a technical foundation
> a lot less frequently than you do. That said, I do think an
> understanding of which technical factors are important is something
> we need to do.
> 
> If there are things I can to to help you believe that we did
> consider the points you think important I'd like to do that.  If you
> can think of things I can do to help you gain confidence that we have
> heard you, please let me know.
> 
> That said, I'm hoping you can respect me when I say that hearing you 
> does not mean agreeing with you--not even about what factors are 
> important in making a decision.

Sorry, but a discussion is "just hearing" me, which "does not mean
agreeing" with me. It is the exchange of arguments. So, if you disagree
on the technical aspects, please put your arguments here. If you think
we don't discuss the important factors for making a decision, please
move the discussion into the right direction. See if you can convince
me. And/or see if you can convince d-i.

But please be transparent in your work.

Just writing an unspecific "hearing does not mean agreeing" doesn't help
to solve the conflict.

Best regards

Ole

[1] https://www.debian.org/devel/tech-ctte

Message #586 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ole Streicher <olebole@debian.org>

Cc: 846002@bugs.debian.org, Margarita Manterola <marga@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Wed, 01 Feb 2017 10:37:41 -0500

>>>>> "Ole" == Ole Streicher <olebole@debian.org> writes:

Georg commented that if we're going to delegate to D-I, we should hurry
up and do so unless this turn into another TC failure.
I personally think we've taken long enough this is already a TC failure
and have expressed regret for my actions that contributed to that.
Marga took an action to close this bug at the previous meeting.  I don't
think I'm slowing her down by continuing to try and explain where I see
things.
I'm certainly not asking her to wait on this discussion.

    >> So, I think the TC will make its decisions on a technical
    >> foundation a lot less frequently than you do. That said, I do
    >> think an understanding of which technical factors are important
    >> is something we need to do.
    >> 
    >> If there are things I can to to help you believe that we did
    >> consider the points you think important I'd like to do that.  If
    >> you can think of things I can do to help you gain confidence that
    >> we have heard you, please let me know.
    >> 
    >> That said, I'm hoping you can respect me when I say that hearing
    >> you does not mean agreeing with you--not even about what factors
    >> are important in making a decision.

    Ole> Sorry, but a discussion is "just hearing" me, which "does not
    Ole> mean agreeing" with me. It is the exchange of arguments. So, if
    Ole> you disagree on the technical aspects, please put your
    Ole> arguments here. If you think we don't discuss the important
    Ole> factors for making a decision, please move the discussion into
    Ole> the right direction. See if you can convince me. And/or see if
    Ole> you can convince d-i.

I'm sorry, but I'd like to be heard differently.  I offered to do what I
could to give you confidence that your points had been heard, understood
and considered.  Now I'm hearing you say that I'm obligated to discuss
with you and to try and convince you that I'm right.  I disagree that
would be valuable here.  I'm not interested in persuading you.  If it's
valuable to you, I'd be happy to work with you to understand what I see
is important here, but that's very different to having a discussion
where one side persuades another or where we make a decision together.
My personal opinion is that collaborative discussion is the kind of
discussion you should try to have with the D-I team early in the buster
cycle.

    Ole> But please be transparent in your work.

All the discussions we've had on this issue have been in public email or
public IRC logs; I think we've been fairly transparent.
My reading of that is that the consensus of the TC is that the D-I team
should make this decision.
I'm not sure the TC as a whole has a consistent rationale.
For myself, I believe the important questions are

1) Should the user be shown a lists of blends during the install process
and asked to choose from them.

2) For any given change, is the particular change mature enough to
include.

I believe there are important issues to balance in terms of number of
prompts, style of user interaction, and risk we're willing to take at
various points in the release process.  I believe the D-I team has
traditionally balanced those issues quite well, so I'd delegate this
decision to them.

I think the question of whether to use package priority, whether to
merge things into tasksel, and the specific content of the menus are
secondary to those two technical questions above.

I have reason to believe some other TC members have thinking similar to
mine.  However, the area where I think we have a consensus is on who
should decide here, *not* on why that's the right decision.

Sometimes not having agreement on the why is a sign of false consensus.
Especially when we're choosing not to act, and in this particular
instance, I don't think this is a false consensus.
I think voting on this might have been a good idea, but Marga does not
wish to call for votes on her ballot and I do not wish to force the
issue by calling for a vote on someone else's ballot.

Message #591 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@debian.org>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>, Margarita Manterola <marga@debian.org>, Cyril Brulebois <kibi@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Wed, 1 Feb 2017 17:32:26 +0000

Sam Hartman writes ("Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu"):
> My reading of that is that the consensus of the TC is that the D-I team
> should make this decision.

I can see why Ole is frustrated.  I don't think this is a proper
conclusion for the TC to reach.

The request to the TC was for a review of a technical decision.  That
means that the TC ought to review the technical decision, not simply
say that the people who made the decision were the ones who should
make it.

A proper conclusion for the TC to reach might be something like:

  We agree with the D-I team's decision for stretch.

  We want to see this improved in buster.  If no solution
  (satisfactory to all sides) is found within 6 months of buster being
  open, we should be asked to revisit the decision.

Or

  We feel that Phil's proposed new menu question is a good way of
  solving this problem, and that the problem is important enough and
  the risk low enough that we want to see this in stretch.

  Accordingly we ask that the D-I team make arrangements to include
  a new question along the lines which have been suggested.

It seems that the TC prefer the first of these but are unwilling to
come out and say so.

> I'm not sure the TC as a whole has a consistent rationale.

Firstly: it's one thing not to have a consistent rationale.  It's
quite another to duck making decision because you can't agree on a
rationale.

Secondly: if there are competing rationales, let each TC member with a
rationale put their own forward.  The matter can then be resolved by a
vote.

I wish the TC were more willing to have divided votes.  It is not
necessary for the TC to reach internal consensus.  It would be much
better to have a 3:2 TC vote on something like this, than weeks and
months of delay followed by a lack of any concrete decision.

> I believe there are important issues to balance in terms of number of
> prompts, style of user interaction, and risk we're willing to take at
> various points in the release process.  I believe the D-I team has
> traditionally balanced those issues quite well, so I'd delegate this
> decision to them.

I think it is quite wrong for the TC or its members to delegate their
decisonmaking back to the maintainer(s) that the petitioner is in
disagreement with.

If those maintainers cannot explain themselves sufficiently to
convince the TC, then the decision should go against them.

Conversely, if those maintainers _do_ explain themselves sufficiently
to convince the TC (as seems to have happened here), then the TC
should say "we have been convinced of XYZ by the maintainers".

Ian.

Message #596 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Margarita Manterola <marga@debian.org>

To: 846002@bugs.debian.org

Subject: Call for votes on resolution for #846002 (blends-tasks)

Date: Wed, 1 Feb 2017 22:58:04 +0100

[Message part 1 (text/plain, inline)]

I call for votes on the following resolution with regards to #846002:

==== RESOLUTION ====

Background

The blends-tasks package was uploaded in April 2016 setting its priority to
important.  The result of this change was that the package started getting
automatically installed by debootstrap, with the intended effect of causing the
list of tasks shipped by the package to be displayed by tasksel in the
debian-installer.

Even though the debian-installer maintainer complained in May 2016 that he did
not agree with this approach with regards to including external packages in the
default tasksel screen, the important priority remains until today.

In December 2016, changes were made in the tasksel package so that it no longer
automatically displays external tasks as part of the debian-installer.

The current state is that chroots created by debootstrap in unstable or testing
include the blends-tasks package, although the shipped tasks are not getting
displayed during the default installation.

In #846002, the Technical Committee was asked by Holger Levsen to rule on the
priority of the blends-tasks package.  In the discussion that followed, the
Committee was asked by Ole Streicher to additionally rule on whether the Blends
selection should be part of the Debian Stretch installer and who should maintain
the list of options displayed to the user in the future.

Using the power of the Technical Committee to make a decision when asked to do
so (§6.1.3):

1. We acknowledge that the decision of which tasks to display during
installation falls within the jurisdiction of the debian-installer maintainers.

2. In the Committee's opinion the use of important priority is not appropriate
for the blends-tasks package according to the definition in the Debian policy
(§2.5).  As it was set only as a means to an end, and since it no longer does
what was intended, we recommend that this change gets reverted.

3. We encourage the debian-installer maintainers to work together with other
teams -including the blends-tasks maintainers- to provide useful and popular
package selections through the debian-installer in future releases.

==== END OF RESOLUTION ====

Please vote [A] for acknowledging that this is under the jurisdiction of the
debian-installer maintainers, and [FD] for Further Discussion.

-- 
Regards,
Marga

[signature.asc (application/pgp-signature, inline)]

Message #601 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Margarita Manterola <marga@debian.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Date: Wed, 1 Feb 2017 23:08:04 +0100

[Message part 1 (text/plain, inline)]

> ==== RESOLUTION ====
> 
> Background
> 
> The blends-tasks package was uploaded in April 2016 setting its priority to
> important.  The result of this change was that the package started getting
> automatically installed by debootstrap, with the intended effect of causing the
> list of tasks shipped by the package to be displayed by tasksel in the
> debian-installer.
> 
> Even though the debian-installer maintainer complained in May 2016 that he did
> not agree with this approach with regards to including external packages in the
> default tasksel screen, the important priority remains until today.
> 
> In December 2016, changes were made in the tasksel package so that it no longer
> automatically displays external tasks as part of the debian-installer.
> 
> The current state is that chroots created by debootstrap in unstable or testing
> include the blends-tasks package, although the shipped tasks are not getting
> displayed during the default installation.
> 
> In #846002, the Technical Committee was asked by Holger Levsen to rule on the
> priority of the blends-tasks package.  In the discussion that followed, the
> Committee was asked by Ole Streicher to additionally rule on whether the Blends
> selection should be part of the Debian Stretch installer and who should maintain
> the list of options displayed to the user in the future.
> 
> Using the power of the Technical Committee to make a decision when asked to do
> so (§6.1.3):
> 
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer maintainers.
> 
> 2. In the Committee's opinion the use of important priority is not appropriate
> for the blends-tasks package according to the definition in the Debian policy
> (§2.5).  As it was set only as a means to an end, and since it no longer does
> what was intended, we recommend that this change gets reverted.
> 
> 3. We encourage the debian-installer maintainers to work together with other
> teams -including the blends-tasks maintainers- to provide useful and popular
> package selections through the debian-installer in future releases.
> 
> ==== END OF RESOLUTION ====
> 
> Please vote [A] for acknowledging that this is under the jurisdiction of the
> debian-installer maintainers, and [FD] for Further Discussion.

I vote A > FD

-- 
Regards,
Marga

[signature.asc (application/pgp-signature, inline)]

Message #606 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Date: Thu, 02 Feb 2017 07:55:20 +0100

[Message part 1 (text/plain, inline)]

> ==== RESOLUTION ====
> 
> Background
> 
> The blends-tasks package was uploaded in April 2016 setting its priority to
> important.  The result of this change was that the package started getting
> automatically installed by debootstrap, with the intended effect of causing
> the list of tasks shipped by the package to be displayed by tasksel in the
> debian-installer.
> 
> Even though the debian-installer maintainer complained in May 2016 that he
> did not agree with this approach with regards to including external
> packages in the default tasksel screen, the important priority remains
> until today.
> 
> In December 2016, changes were made in the tasksel package so that it no
> longer automatically displays external tasks as part of the
> debian-installer.
> 
> The current state is that chroots created by debootstrap in unstable or
> testing include the blends-tasks package, although the shipped tasks are
> not getting displayed during the default installation.
> 
> In #846002, the Technical Committee was asked by Holger Levsen to rule on
> the priority of the blends-tasks package.  In the discussion that followed,
> the Committee was asked by Ole Streicher to additionally rule on whether
> the Blends selection should be part of the Debian Stretch installer and who
> should maintain the list of options displayed to the user in the future.
> 
> Using the power of the Technical Committee to make a decision when asked to
> do so (§6.1.3):
> 
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer
> maintainers.
> 
> 2. In the Committee's opinion the use of important priority is not
> appropriate for the blends-tasks package according to the definition in the
> Debian policy (§2.5).  As it was set only as a means to an end, and since
> it no longer does what was intended, we recommend that this change gets
> reverted.
> 
> 3. We encourage the debian-installer maintainers to work together with other
> teams -including the blends-tasks maintainers- to provide useful and
> popular package selections through the debian-installer in future releases.
> 
> ==== END OF RESOLUTION ====

I vote A > FD

-- 
    OdyX

[signature.asc (application/pgp-signature, inline)]

Message #611 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Thu, 02 Feb 2017 19:47:08 +0100

]] Ole Streicher 

> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
> > If you go back one meeting further, my interpretation is that the consensus of
> > the committee seems to be that ultimately this decision belongs to the
> > installer team.
> > That is, in this case, a number of members on the TC seem to believe
> > that the installer team gets to decide whether/how the installer makes
> > it easy to install blends.
> > If they don't want to do that for stretch, that's a decision within
> > their pervue that we clearly don't have the votes to override.
> 
> Hmm, IMO there are two things here: First, in our constitution, the
> installer team has no specific granted rights, apart from being
> maintainers of the relevant packages. This makes the conflict primarily
> a conflict between developers having different opinions about how to
> solve a certain problem. A decision here falls under the rights
> granted to the Technical Team by the Project leader. And I would expect
> that a decision would be made on some technical foundation.

I don't see why this is particularly relevant?  The d-i team is quite
clearly the maintainers of the installer, not just the individual
packages.  This has been the case in the past as well, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367709 for instance.

So, you're asking the installer to change (or, depending on how strong
language one wants to use, subverting the technical mechanisms that are
in place already), and the maintainers are unwilling to accomodate you.

[...]

> We all agree here that the menu is confusing, and that the Blends
> entries don't make it better. The primary question here is however: does
> it really make it so much worse that we can't include it in Stretch?

I think an argument from a position of «this only makes it a little bit
worse» is pretty weak: for me to support overriding the maintainer, you
would have to make it substantially better, not just a little bit worse.

> Compared to the LXQt menu entry addition? At least I doubt that (not
> surprisingly), and I tried to put my arguments here.

Personally, I don't see the big point of adding LXQt to the list, but on
the other hand, I don't think the tech committee should micromanage (and
arguably, we're not allowed to, depending on whether that'd be «detailed
design work» or not).

> It is *not* about just "hey, d-i decided that way. Sorry, we can't do
> anything here". It is about to help us (d-blends and d-i) to sort out
> the technical aspects, to weight them and to come to a solution where
> everyone can agree as much as possible.

I didn't read Sam's response as «we can't do anything», but rather that
we (the TC) are unwilling to override the d-i maintainers.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #616 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Date: Thu, 02 Feb 2017 19:50:05 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

]] Margarita Manterola 

> Please vote [A] for acknowledging that this is under the jurisdiction of the
> debian-installer maintainers, and [FD] for Further Discussion.

I vote A > FD.

- -- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAliTf10ACgkQtlpIccoZ
1xfFZBAA0xrmk4V7TG+RkANTzTSZY8seiAuyW+dRX+3E91cu18C86+hu/XLI/7T4
3V0mON2FOF15di3v+Ag+d2OmmoxvAbsGtDa5EIT1xNbk1oQxBdeVD22hzpt4Q0+l
OHjdCDej+2K9MYpDMb6+Yjc5bq/RjVnFpVWkpRXQAXlbqJfi0kUH0uL9WkTf+K1u
5pyjlDKro2tw74OiTEIOYoGgaml4dlq1UYC2bu5ijSZb4EndX/OjT+eI6Desmyog
AynjcbWDcLfWIw9/eNG7udFSo69fIOVAnZVSc5ipI4MnslsCDBaOYgHSlPTyMuG3
YdXe03G0xTyqC4HE2wnXpPpEr+pHZg3MRpCmwJu8qL6vfAzTR/bW7SUI16G4FZ34
2zBNwCpJDU938CJFXHF0XFPJhn4A0NVRPdiflRvZy4rQ7taihkeGncmLo9sGz9x8
J8kCEPtNIJS0Ckf3Q5dwwsuYY2S6cp5fxrXQGyIIYtbJBcjEdkeXm3wr/By9+KoK
2oLBaVYwIdhof6XYSGorpyoxlF2PRXwhu458tsxPWjQRN5AiAlO3VofHPalhP5SQ
2yns9F066K/9HlDoE5NzxklTh11qWYuxrQoqs4gFvEmhU9i+xpCCCuPR90Tlmqpw
rOq/XK8B1vJoWXyUM8Bm5qHpocaO+pIC6TtZQV6tTbr73ENyAok=
=lB6H
-----END PGP SIGNATURE-----

Message #621 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <ole.streicher@gmx.de>

To: Tollef Fog Heen <tfheen@err.no>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Thu, 2 Feb 2017 20:52:23 +0100

Hi Tollef

On 02.02.2017 19:47, Tollef Fog Heen wrote:
> ]] Ole Streicher 
> 
>> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
>>> If you go back one meeting further, my interpretation is that the consensus of
>>> the committee seems to be that ultimately this decision belongs to the
>>> installer team.
>>> That is, in this case, a number of members on the TC seem to believe
>>> that the installer team gets to decide whether/how the installer makes
>>> it easy to install blends.
>>> If they don't want to do that for stretch, that's a decision within
>>> their pervue that we clearly don't have the votes to override.
>>
>> Hmm, IMO there are two things here: First, in our constitution, the
>> installer team has no specific granted rights, apart from being
>> maintainers of the relevant packages. This makes the conflict primarily
>> a conflict between developers having different opinions about how to
>> solve a certain problem. A decision here falls under the rights
>> granted to the Technical Team by the Project leader. And I would expect
>> that a decision would be made on some technical foundation.
> 
> I don't see why this is particularly relevant?  The d-i team is quite
> clearly the maintainers of the installer, not just the individual
> packages.  This has been the case in the past as well, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367709 for instance.
> 
> So, you're asking the installer to change (or, depending on how strong
> language one wants to use, subverting the technical mechanisms that are
> in place already), and the maintainers are unwilling to accomodate you.

This makes it a case where one can ask the TC for a decision, if an
otherwise unresolvable conflict appears. And IMO the TC has the power to
decide here. I have read Sams "vote to override" as "power to override",
and this was where I disagree.

>> We all agree here that the menu is confusing, and that the Blends
>> entries don't make it better. The primary question here is however: does
>> it really make it so much worse that we can't include it in Stretch?
> 
> I think an argument from a position of «this only makes it a little bit
> worse» is pretty weak: for me to support overriding the maintainer, you
> would have to make it substantially better, not just a little bit worse.

The argument making is better is that (potential) users of the blends
have it easier to find and install the blend. These are, BTW the points
I expected to be discussed here before the voting comes out, and not after.

>> Compared to the LXQt menu entry addition? At least I doubt that (not
>> surprisingly), and I tried to put my arguments here.
> 
> Personally, I don't see the big point of adding LXQt to the list, but on
> the other hand, I don't think the tech committee should micromanage (and
> arguably, we're not allowed to, depending on whether that'd be «detailed
> design work» or not).

An argument of d-i is: We know that it is already pretty confusing now,
but it is a compromise, and we don't want to make it worse. Adding LXQt
*makes* it worse, so it invalidates this argument.

>> It is *not* about just "hey, d-i decided that way. Sorry, we can't do
>> anything here". It is about to help us (d-blends and d-i) to sort out
>> the technical aspects, to weight them and to come to a solution where
>> everyone can agree as much as possible.
> 
> I didn't read Sam's response as «we can't do anything», but rather that
> we (the TC) are unwilling to override the d-i maintainers.

He wrote "we don't have the vote to override", and this is IMO wrong.
The TC has the power to decide here, and you were asked to do so. If you
think that d-i took the right decision, you should decide so (and then
you don't need to use your power), but not just let them decide. I agree
here fully Ian:

Ian Jackson wrote:
> I think it is quite wrong for the TC or its members to delegate their
> decisonmaking back to the maintainer(s) that the petitioner is in
> disagreement with.

Best regards

Ole

Message #626 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Thu, 02 Feb 2017 21:29:46 +0100

]] Ole Streicher 

Hi

> >> Am 31.01.2017 um 16:26 schrieb Sam Hartman:

[...]

> >>> If they don't want to do that for stretch, that's a decision within
> >>> their pervue that we clearly don't have the votes to override.

[...]

> This makes it a case where one can ask the TC for a decision, if an
> otherwise unresolvable conflict appears. And IMO the TC has the power to
> decide here. I have read Sams "vote to override" as "power to override",
> and this was where I disagree.

My mind-reading skills are not great, but I don't think that was what
Sam meant.  He wrote «votes to override» (note the plural), which, to
me, means «there are not enough people who agree that this should be
overridden», not «we don't have the power to override this (regardless
of the number of votes».

> > Personally, I don't see the big point of adding LXQt to the list, but on
> > the other hand, I don't think the tech committee should micromanage (and
> > arguably, we're not allowed to, depending on whether that'd be «detailed
> > design work» or not).
> 
> An argument of d-i is: We know that it is already pretty confusing now,
> but it is a compromise, and we don't want to make it worse. Adding LXQt
> *makes* it worse, so it invalidates this argument.

Not really.  It weakens it, but it doesn't invalidate it. 

> >> It is *not* about just "hey, d-i decided that way. Sorry, we can't do
> >> anything here". It is about to help us (d-blends and d-i) to sort out
> >> the technical aspects, to weight them and to come to a solution where
> >> everyone can agree as much as possible.
> > 
> > I didn't read Sam's response as «we can't do anything», but rather that
> > we (the TC) are unwilling to override the d-i maintainers.
> 
> He wrote "we don't have the vote to override", and this is IMO wrong.

No, he wrote «we don't have the votes to override».  The plural here is
crucial.

> The TC has the power to decide here, and you were asked to do so. If you
> think that d-i took the right decision, you should decide so (and then
> you don't need to use your power), but not just let them decide.

That's what the current ballot effectively says.  We're refusing to
override the d-i team.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #631 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Asusena Hernandez <asusenahernandez47@gmail.com>

To: Bjørn Mork <bjorn@mork.no>

Cc: 846002@bugs.debian.org, Debian Developers <debian-devel@lists.debian.org>, debian-boot@lists.debian.org, Andreas Tille <tille@debian.org>

Subject: Re: Congratulation:Benjamin_Eligibility for Fresh Start Tax Program F3pe198.9.78.72.9.148.37221.123.0.5F3pe

Date: Thu, 2 Feb 2017 15:06:51 -0700

[Message part 1 (text/plain, inline)]

On Jan 17, 2017 12:40 PM, "Bjørn Mork" <bjorn@mork.no> wrote:

> dfhg
>
> Benjamin_Qualify_for_Tax_Debt_ Relief?
>
> Check_Your_Eligibility
>
>
>
>
> <http://unige.ch/biblio/plus/ressources/rep_redirect.php?nom=The+World+Atlas+of+Language+Structures+Online&url=http%3A%2F%2Furlurl.link/gO3f6>
> <http://unige.ch/biblio/plus/ressources/rep_redirect.php?nom=The+World+Atlas+of+Language+Structures+Online&url=http%3A%2F%2Furlurl.link/pIp0d>
> <http://unige.ch/biblio/plus/ressources/rep_redirect.php?nom=The+World+Atlas+of+Language+Structures+Online&url=http%3A%2F%2Furlurl.link/Ix7dT>
> asdf
> asdf
> asdf
>
>

[Message part 2 (text/html, inline)]

Message #636 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ole Streicher <olebole@debian.org>

To: Tollef Fog Heen <tfheen@err.no>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Fri, 3 Feb 2017 10:32:20 +0100

Hi Tollef,

On 02.02.2017 21:29, Tollef Fog Heen wrote:
> ]] Ole Streicher 
>>>> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
>>>>> If they don't want to do that for stretch, that's a decision within
>>>>> their pervue that we clearly don't have the votes to override.
>> I have read Sams "vote to override" as "power to override",
>> and this was where I disagree.
> 
> My mind-reading skills are not great, but I don't think that was what
> Sam meant.  He wrote «votes to override» (note the plural), which, to
> me, means «there are not enough people who agree that this should be
> overridden», not «we don't have the power to override this (regardless
> of the number of votes».

Yea, I should improve my reading skills for english. This is my
misunderstanding. However, if this refers to the number of votes within
TC (right?), counting that would have been part of the decision.

>>> Personally, I don't see the big point of adding LXQt to the list, but on
>>> the other hand, I don't think the tech committee should micromanage (and
>>> arguably, we're not allowed to, depending on whether that'd be «detailed
>>> design work» or not).
>>
>> An argument of d-i is: We know that it is already pretty confusing now,
>> but it is a compromise, and we don't want to make it worse. Adding LXQt
>> *makes* it worse, so it invalidates this argument.
> 
> Not really.  It weakens it, but it doesn't invalidate it.

I am not sure if it is worth to discuss this further (at least unless
the initiated vote fails). Again, this discussion could have been useful
before a voting, and I expected exactly that to happen here before the
voting starts.

It should have been part of the way you come to a conclusion, and maybe
even to convince me. Or maybe KiBi.

>> The TC has the power to decide here, and you were asked to do so. If you
>> think that d-i took the right decision, you should decide so (and then
>> you don't need to use your power), but not just let them decide.
> 
> That's what the current ballot effectively says.  We're refusing to
> override the d-i team.

No, this is a difference. I asked to decide whether the blends menu
should go into the installer (in one or the other way), questioning the
decision of d-i, and you (resp. those who select "A > FD") delegate the
question back to d-i, without having a detailed technical discussion.
Ian made the point here, IMO, and I wonder a bit why his critics remains
unanswered.

Just have a look into the voting proposal:

Margarita Manterola writes:
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer maintainers.

There is no discussion at all whether the benefits of the blends menu
overtake the disadvantaged of the current solution. This is just the
formal common statement that one should not override it from outside; so
you certainly do not accept other (non-d-i) packages to put a menu there
(which is then specified in the second item, regarding the solution we
made here).

This however just answer the question of who usually shall decide on it.
I does *not* answer the specific question, whether the blends menu
should be in the installer (since the TC could override the d-i decision
even if it acknowledges that they should decide). The answer to the
latter is just given by *not* taking a decision, by *not* discussing
this aspect here, even if asked so. IMO this ignores the goal of the TC
(again, see Ians argument; he had a good wording for that).

Best regards

Ole

Message #641 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Ole Streicher <olebole@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Fri, 03 Feb 2017 11:09:11 +0100

[Message part 1 (text/plain, inline)]

Ole Streicher <olebole@debian.org> writes:

...
>>> The TC has the power to decide here, and you were asked to do so. If you
>>> think that d-i took the right decision, you should decide so (and then
>>> you don't need to use your power), but not just let them decide.
>> 
>> That's what the current ballot effectively says.  We're refusing to
>> override the d-i team.
>
> No, this is a difference. I asked to decide whether the blends menu
> should go into the installer (in one or the other way), questioning the
> decision of d-i, and you (resp. those who select "A > FD") delegate the
> question back to d-i, without having a detailed technical discussion.
> Ian made the point here, IMO, and I wonder a bit why his critics remains
> unanswered.

I think this is in part a symptom of mixing up multiple questions in one
request.

There seems to be a consensus that the priority change was misguided,
and that's the thing that is primarily being decided here.

If I had had more time in the last month, I'd have put some work into
producing and testing a patch to tasksel to get the blends back in
without the priority changes.  Sadly I've not had that time, and I
suspect that we're too late for such things now.

Personally I think that Cyril's patch to strip out the blends-tasks
tasks was also a mistake -- hopefully we can now revert both the
priority change, and that reaction to it.

I do have time now, so perhaps while we're reverting those changes Cyril
will be open to persuasion that we could also patch the blends back in,
and make the menu clearer overall using my early suggestion of prefixing
the title lines with ===, but I'm certainly not willing to try and force
that decision on him with my TC stick.

The reason I've been mostly quiet on this subject is that I feel like I
have something of a conflict of interest, also being a (mostly lapsed)
D-I team member, so I've been restricting myself to attempting to
propose possible solutions.

I don't know why anyone else didn't respond to Ian's criticism, but for
my part I didn't think it was even slightly helpful for him to be in
effect pushing me further towards the conflict of interest that I'm
attempting to avoid.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #646 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Margarita Manterola <marga@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Date: Fri, 03 Feb 2017 11:34:14 +0100

[Message part 1 (text/plain, inline)]

Margarita Manterola <marga@debian.org> writes:

> I call for votes on the following resolution with regards to #846002:
>
> ==== RESOLUTION ====
>
> Background
>
> The blends-tasks package was uploaded in April 2016 setting its priority to
> important.  The result of this change was that the package started getting
> automatically installed by debootstrap, with the intended effect of causing the
> list of tasks shipped by the package to be displayed by tasksel in the
> debian-installer.
>
> Even though the debian-installer maintainer complained in May 2016 that he did
> not agree with this approach with regards to including external packages in the
> default tasksel screen, the important priority remains until today.
>
> In December 2016, changes were made in the tasksel package so that it no longer
> automatically displays external tasks as part of the debian-installer.
>
> The current state is that chroots created by debootstrap in unstable or testing
> include the blends-tasks package, although the shipped tasks are not getting
> displayed during the default installation.
>
> In #846002, the Technical Committee was asked by Holger Levsen to rule on the
> priority of the blends-tasks package.  In the discussion that followed, the
> Committee was asked by Ole Streicher to additionally rule on whether the Blends
> selection should be part of the Debian Stretch installer and who should maintain
> the list of options displayed to the user in the future.
>
> Using the power of the Technical Committee to make a decision when asked to do
> so (§6.1.3):
>
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer maintainers.
>
> 2. In the Committee's opinion the use of important priority is not appropriate
> for the blends-tasks package according to the definition in the Debian policy
> (§2.5).  As it was set only as a means to an end, and since it no longer does
> what was intended, we recommend that this change gets reverted.
>
> 3. We encourage the debian-installer maintainers to work together with other
> teams -including the blends-tasks maintainers- to provide useful and popular
> package selections through the debian-installer in future releases.
>
> ==== END OF RESOLUTION ====
>
> Please vote [A] for acknowledging that this is under the jurisdiction of the
> debian-installer maintainers, and [FD] for Further Discussion.

Since I feel a conflict of interest due to being a D-I team member,
I'll abstain.

If that's unhelpful for some reason, feel free to record my vote as:

  A == FD

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #651 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Philip Hands <phil@hands.com>, 846002@bugs.debian.org

Cc: Ole Streicher <olebole@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Fri, 3 Feb 2017 14:10:43 +0100

[Message part 1 (text/plain, inline)]

Since I've been asked in an IRC query whether I might be willing to
consider this suggestion:

Philip Hands <phil@hands.com> (2017-02-03):
> I think this is in part a symptom of mixing up multiple questions in
> one request.
> 
> There seems to be a consensus that the priority change was misguided,
> and that's the thing that is primarily being decided here.
> 
> If I had had more time in the last month, I'd have put some work into
> producing and testing a patch to tasksel to get the blends back in
> without the priority changes.  Sadly I've not had that time, and I
> suspect that we're too late for such things now.
> 
> Personally I think that Cyril's patch to strip out the blends-tasks
> tasks was also a mistake -- hopefully we can now revert both the
> priority change, and that reaction to it.
> 
> I do have time now, so perhaps while we're reverting those changes
> Cyril will be open to persuasion that we could also patch the blends
> back in, and make the menu clearer overall using my early suggestion
> of prefixing the title lines with ===

Sure! Feel free to prepare improvements to be reviewed, merged, and
tested at the beginning of the buster release cycle.

> but I'm certainly not willing to try and force that decision on him
> with my TC stick.

Thank you.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #656 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@mit.edu>

To: Margarita Manterola <marga@debian.org>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Date: Fri, 03 Feb 2017 13:30:47 -0500

[Message part 1 (text/plain, inline)]

I vote A -> FD for the blends-tasks vote.

[signature.asc (application/pgp-signature, inline)]

Message #661 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ole Streicher <olebole@debian.org>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Fri, 03 Feb 2017 13:50:34 -0500

[Message part 1 (text/plain, inline)]

Hi, first, you've made the point that you were hoping the TC would help
the blends team and the d-i team work together.
I think that Phil's suggestions for a technical approach are quite good,
and I hope that will move forward in the buster cycle.

With regard to stretch, I honestly don't think there is anything that we
can do that we believe that we should do.
Some of us think Cyril might  being overly conservative in his initial
decision.  I suspect though that we almost all believe that now is way
too late.
Also, I think all the TC members believe that Cyril is the one who
ultimately should have made the is it too late decision for stretch.
I don't think there's more information he could have been given that
would have helped with that.

"You'll get what you want, but not in the time line you want," is a
frustrating outcome.
However, it is the kind of compromise that is often right in this
situation.


>>>>> "Ole" == Ole Streicher <olebole@debian.org> writes:

    Ole> Yea, I should improve my reading skills for english. This is my
    Ole> misunderstanding. However, if this refers to the number of
    Ole> votes within TC (right?), counting that would have been part of
    Ole> the decision.

The TC has to vote in order to override someone or to use its
constitutional powers.  The TC doesn't need to "vote" in order to decide
to support an existing decision; we can do this by consensus.

We didn't need to hold a vote for me to read the discussion and have
high personal confidence that there would be insufficient votes to
support your position.  marga proposed closing the bug--deciding by
consensus.  No one on the TC .objected to doing that.  That's a fairly
good sign in our processes it is the right decision.  She ended up
deciding to call for a vote.  Based on the results of that vote it seems
fairly clear it would have been reasonable to close the vote by
consensus as well.

Votes are kind of a crappy way to  make such decisions.

[signature.asc (application/pgp-signature, inline)]

Message #666 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Margarita Manterola <marga@debian.org>, 846002@bugs.debian.org, 846002@bugs.debian.org

Subject: Re: Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Date: Sat, 04 Feb 2017 10:35:25 +0100

[Message part 1 (text/plain, inline)]

Margarita Manterola <marga@debian.org> writes:

> I call for votes on the following resolution with regards to #846002:

I vote A > FD.

-- 
-keith

[signature.asc (application/pgp-signature, inline)]

Message #671 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tille@debian.org>

To: Cyril Brulebois <kibi@debian.org>, 846002@bugs.debian.org

Cc: Philip Hands <phil@hands.com>, Ole Streicher <olebole@debian.org>

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Sat, 4 Feb 2017 12:16:01 +0100

On Fri, Feb 03, 2017 at 02:10:43PM +0100, Cyril Brulebois wrote:
> > 
> > I do have time now, so perhaps while we're reverting those changes
> > Cyril will be open to persuasion that we could also patch the blends
> > back in, and make the menu clearer overall using my early suggestion
> > of prefixing the title lines with ===
> 
> Sure! Feel free to prepare improvements to be reviewed, merged, and
> tested at the beginning of the buster release cycle.

Would it be a sensible compromise to reassign this bug to d-i tagging it
RC for buster to make sure a Blends menu will exist in the buster
installer.  I admit I'm frustrated as well but it does not really matter
for me whether I'm waiting 14 (first bug report about this was #186085
in 2003) or 16 years until a good idea gets implemented preserving me
from continuously explaining that Blends are inside Debian and not
outside.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Message #676 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Asusena Hernandez <asusenahernandez47@gmail.com>

To: 846002@bugs.debian.org

Subject: Re: Bug#846002: Info received (Congratulation:Benjamin_Eligibility for Fresh Start Tax Program F3pe198.9.78.72.9.148.37221.123.0.5F3pe)

Date: Sat, 4 Feb 2017 06:07:41 -0700

[Message part 1 (text/plain, inline)]

On Feb 2, 2017 4:09 PM, "Debian Bug Tracking System" <owner@bugs.debian.org>
wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Technical Committee <debian-ctte@lists.debian.org>
>
> If you wish to submit further information on this problem, please
> send it to 846002@bugs.debian.org.
>
> Please do not send mail to owner@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 846002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002
> Debian Bug Tracking System
> Contact owner@bugs.debian.org with problems
>

[Message part 2 (text/html, inline)]

Message #681 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: Andreas Tille <tille@debian.org>

Cc: 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Sun, 05 Feb 2017 00:38:59 +0100

]] Andreas Tille 

> On Fri, Feb 03, 2017 at 02:10:43PM +0100, Cyril Brulebois wrote:
> > > 
> > > I do have time now, so perhaps while we're reverting those changes
> > > Cyril will be open to persuasion that we could also patch the blends
> > > back in, and make the menu clearer overall using my early suggestion
> > > of prefixing the title lines with ===
> > 
> > Sure! Feel free to prepare improvements to be reviewed, merged, and
> > tested at the beginning of the buster release cycle.
> 
> Would it be a sensible compromise to reassign this bug to d-i tagging it
> RC for buster to make sure a Blends menu will exist in the buster
> installer.

While I think it's important to get it fixed for buster, I don't think
it's RC.  If the d-i folks and/or the release team disagrees, I'm happy
for them to decide otherwise, though. 

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #686 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Andreas Tille <tille@debian.org>, 846002@bugs.debian.org

Subject: Re: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Date: Mon, 6 Feb 2017 09:07:31 +0000

[Message part 1 (text/plain, inline)]

On Sat, Feb 04, 2017 at 12:16:01PM +0100, Andreas Tille wrote:
> Would it be a sensible compromise to reassign this bug to d-i tagging it
> RC for buster to make sure a Blends menu will exist in the buster
> installer. 

besides what Tollef already said about the severity I think a fresh new bug is
much better. When working on said fix, nobody will want to be forced to look
at the history of this bug again…


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #691 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: debian-ctte@lists.debian.org, Debian Pure Blends List <debian-blends@lists.debian.org>

Cc: 846002@bugs.debian.org

Subject: About the internal and external view of Blends (Was: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu)

Date: Mon, 6 Feb 2017 14:43:54 +0100

Hi,

On Sun, Feb 05, 2017 at 12:38:59AM +0100, Tollef Fog Heen wrote:
> > Would it be a sensible compromise to reassign this bug to d-i tagging it
> > RC for buster to make sure a Blends menu will exist in the buster
> > installer.
> 
> While I think it's important to get it fixed for buster, I don't think
> it's RC.  If the d-i folks and/or the release team disagrees, I'm happy
> for them to decide otherwise, though. 

May be this is the right time to clarify the role of Blends inside
Debian and I'd like to adjust my probably biased opinion.  Do you
consider Blends as

   A) Assemblage of low popcon packages of very specific fields

   B) Strategy to establish Debian in different workfields that
      could cover a wide range of applications

As I said the outer view from users of Debian it is hard to distinguish
between a derivative and a Blend.  From my experiences from DebConfs
talks (which I'm holding since 2003) are not attracting many people
which makes me consider that A is a widely spread inner view inside the
Debian developers.  Sometimes when it comes to what I consider pure side
effects of the Blends effort like how to attract new developers for your
team[1] people consider the concept quite interesting.  Quoting Asheesh
Laroia from my talk at DebCOnf13[1]:  "Is there a topic you care about,
create a Blend today." ([1] 38:45) - my answer was "This is what I'm
doing so since 2003."

In a discussion with Bdale on a conference in Malaga he even expressed
the idea that it might be feasible to distribute Debian as a set of
Blends (at this time Blends were named differently) and later Bdale
confirmed that he even forgot this idea - may its just me that I just do
not give up on a topic that has catched my interest.

My impression is that the view of the majority of the Debian developers
is basically A which is possibly shared by Tollef when he considers the
importance of the bug not RC.

I think my talk[1] gives good reasons for view B if only people would
try to become more informed about the concept.  My talk[1] - even not
explicitly having Blends in the title (may be thus attracting a far
wider audience - it was even ranked higher and thus made it in the main
talk room at DebConf13 because not mentioning Blends ;-) ) contains a
lot of good reasons for the view B and finally has lead inside the
discussion part to questions of how Blends should be installed.

To not extend this mail to much I just want to address two points.  In
the video[1] starting at minute 3 I'm presenting numbers how many Debian
developers confirmed that they are DDs only for the reason that the
Debian Med project exists.  In my summary for the Debian Med sprint I
have updated numbers[2] that the trend continues and the Debian Med
project attracted 1 developer per year and several of them are doing
other things than only Debian Med work now.  This means a small topic
like medicine and live science which makes a small fraction of Debian
usage and is honestly speaking in the end irrelevant for the overall
importance of Debian in general was able to gather more than 1% of
the active Debian developers.

The other measure is addressing the low popcon packages.  Yes, Debian
Med is mostly about low popcon packages (8 packages > 100 votes) but
when doing last years GSoC I was observing votes more closely to pick
the most used packages for adding autopkgtests.  I noticed that the
number of popcon votes (= really used packages) and I noticed that we
had an increase from 163 packages with >10 votes to 254 packages with
>10 votes in only 3 monthes.  I think this speed of adoption of those
low popcon packages is a consequence that users realise that Debian
cares about the packages they are using.

Despite this effect I know from several personal contacts from this
field, that people stick to Ubuntu with the argument: "Ubuntu is easier
to use."  A very speaking example is: I packaged a software at request
of one of these users for Debian, fighted throug its dependencies and
uploaded the package to backports.  The user who requested the package
keeps on using Ubuntu (since "its easier") but was not able to install
the package in question on Ubuntu (despite I explained how to backport
to Ubuntu).  We could do a pretty good service to this type of user to
make Debian "easy to install".  This installation topic comes up in
every talk I have given (see [1] at 35:20) and since 14 years I can not
give a satisfying answer to the audience.

I could give a lot of other examples and reasons why I think the active
support of Blends inside the Debian infrastructure could have a positive
effekt onto the acceptance of Debian inside these workfields *and*
beyond.  Blends have the power to bump the maintainer-package relation
to a team-topic relation and - provided if done right (we also have
somehow orphaned Blends like Debian Junior) - can enhance the quality of
packages covering a whole topic (see for instance Debian Med advent
calendar[3] to squash bugs and many others).

In short:  If you voted for A above please dive a bit into the topic to
consider B as an option.  When voting B I think it becomes evident that
the bug is RC (at least for Buster).

Kind regards

     Andreas.

[1] https://www.irill.org/videos/debconf13/How_to_attract_new_developers_for_your_team.html
    alternative video location
     http://gensho.acc.umu.se/pub/debian-meetings/2013/debconf13/high/987_How_to_attract_new_developers_for_your_team.ogv
[2] https://people.debian.org/~tille/talks/20170113_debian-med-sprint/sprints+mentoring.pdf#15
[3] http://debian-med.alteholz.de/advent-2016/

-- 
http://fam-tille.de

Message #696 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Andreas Tille <andreas@an3as.eu>

Cc: Debian Pure Blends List <debian-blends@lists.debian.org>, 846002@bugs.debian.org

Subject: Re: About the internal and external view of Blends (Was: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu)

Date: Mon, 6 Feb 2017 18:04:18 +0000

Andreas Tille writes ("About the internal and external view of Blends (Was: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu)"):
> May be this is the right time to clarify the role of Blends inside
> Debian and I'd like to adjust my probably biased opinion.  Do you
> consider Blends as
> 
>    A) Assemblage of low popcon packages of very specific fields
> 
>    B) Strategy to establish Debian in different workfields that
>       could cover a wide range of applications

I think B is awesome.

(And anyway I think low popcon packages are great.)

> To not extend this mail to much I just want to address two points.  In
> the video[1] starting at minute 3 I'm presenting numbers how many Debian
> developers confirmed that they are DDs only for the reason that the
> Debian Med project exists.  In my summary for the Debian Med sprint I
> have updated numbers[2] that the trend continues and the Debian Med
> project attracted 1 developer per year and several of them are doing
> other things than only Debian Med work now.  This means a small topic
> like medicine and live science which makes a small fraction of Debian
> usage and is honestly speaking in the end irrelevant for the overall
> importance of Debian in general was able to gather more than 1% of
> the active Debian developers.

This shows what an untapped potential we have.

> Despite this effect I know from several personal contacts from this
> field, that people stick to Ubuntu with the argument: "Ubuntu is easier
> to use."  A very speaking example is: I packaged a software at request
> of one of these users for Debian, fighted throug its dependencies and
> uploaded the package to backports.  The user who requested the package
> keeps on using Ubuntu (since "its easier") but was not able to install
> the package in question on Ubuntu (despite I explained how to backport
> to Ubuntu).  We could do a pretty good service to this type of user to
> make Debian "easy to install".  This installation topic comes up in
> every talk I have given (see [1] at 35:20) and since 14 years I can not
> give a satisfying answer to the audience.

This must be very frustrating.

I'm afraid I have nothing useful to offer you but I do think this is
all very unsatisfactory.

Ian.

Message #701 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: Debian Pure Blends List <debian-blends@lists.debian.org>, 846002@bugs.debian.org

Subject: Re: About the internal and external view of Blends (Was: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu)

Date: Mon, 6 Feb 2017 19:13:17 +0100

On Mon, Feb 06, 2017 at 06:04:18PM +0000, Ian Jackson wrote:
> > ...
> > to Ubuntu).  We could do a pretty good service to this type of user to
> > make Debian "easy to install".  This installation topic comes up in
> > every talk I have given (see [1] at 35:20) and since 14 years I can not
> > give a satisfying answer to the audience.
> 
> This must be very frustrating.
> 
> I'm afraid I have nothing useful to offer you but I do think this is
> all very unsatisfactory.

Not really.  In my non-computer life I'm doing endurance sport
(bicycling, swimming, running) and so I'm trained to have patience and
endurance.  Seeing how the Debian Med project evolves despite the
attention it would IMHO deserve is great.  Realising that there are
a hand full of other Blends following this success is even greater.

Having continuous hope that at some point in time we will be able to use
this potential keeps me positive and I'll keep on propagating the idea
(instead of giving up and only care for my own pet Debian Med).

Thanks for the moral support

    Andreas.

-- 
http://fam-tille.de

Message #706 received at 846002@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: Andreas Tille <tille@debian.org>

Cc: 846002@bugs.debian.org

Subject: Re: About the internal and external view of Blends

Date: Fri, 17 Feb 2017 20:21:41 +0100

]] Andreas Tille 

Hi,

first of all, sorry for taking a while to get back to you on this.

> Hi,
> 
> On Sun, Feb 05, 2017 at 12:38:59AM +0100, Tollef Fog Heen wrote:
> > > Would it be a sensible compromise to reassign this bug to d-i tagging it
> > > RC for buster to make sure a Blends menu will exist in the buster
> > > installer.
> > 
> > While I think it's important to get it fixed for buster, I don't think
> > it's RC.  If the d-i folks and/or the release team disagrees, I'm happy
> > for them to decide otherwise, though. 
> 
> May be this is the right time to clarify the role of Blends inside
> Debian and I'd like to adjust my probably biased opinion.  Do you
> consider Blends as
> 
>    A) Assemblage of low popcon packages of very specific fields
> 
>    B) Strategy to establish Debian in different workfields that
>       could cover a wide range of applications

No, I don't think either of those are a good description of what blends
are today, nor a sufficient description of what they could, and maybe
should be.

I think Blends are at least two things: They are a focal point for work
on packages in a specific area.  I imagine packages focusing on medical
applications for instance will encounter some of the same challenges,
and having somewhere to hold the more specialised conversations around
those challenges is useful.

They're also curated selections of packages.  Having a blend that is
«every single medical package under the sun» does not sound particularly
useful if it's pulled in as a single metapackage.

> As I said the outer view from users of Debian it is hard to distinguish
> between a derivative and a Blend.  From my experiences from DebConfs
> talks (which I'm holding since 2003) are not attracting many people
> which makes me consider that A is a widely spread inner view inside the
> Debian developers.

I don't see how this follows at all.  People generally scratch their own
itches.  I personally have little interest in, say medical applications
which means I'm not going to spend time and effort on that.  It doesn't
mean that I don't think people who are interested in it shouldn't work
on it: I quite think they should.  At the same time, making a
distribution and getting a release out is about balancing goals,
priorities and sometimes making those hard choices.  It is to say «no,
I'm sorry, this is too late» to somebody who is enthusiastic about a
change.  The flipside is that we get fairly regular releases out so if
you miss a release, it's not the end of the world.

[…]

> To not extend this mail to much I just want to address two points.  In
> the video[1] starting at minute 3 I'm presenting numbers how many Debian
> developers confirmed that they are DDs only for the reason that the
> Debian Med project exists.  In my summary for the Debian Med sprint I
> have updated numbers[2] that the trend continues and the Debian Med
> project attracted 1 developer per year and several of them are doing
> other things than only Debian Med work now.  This means a small topic
> like medicine and live science which makes a small fraction of Debian
> usage and is honestly speaking in the end irrelevant for the overall
> importance of Debian in general was able to gather more than 1% of
> the active Debian developers.

This is great, and it's a pretty common story: people come to scratch
their itch and some then migrate into helping out with other parts of
Debian that catch their interest, be it packages, the installer,
documentation, web pages, release team, translations or something else.

> I could give a lot of other examples and reasons why I think the active
> support of Blends inside the Debian infrastructure could have a positive
> effekt onto the acceptance of Debian inside these workfields *and*
> beyond.  Blends have the power to bump the maintainer-package relation
> to a team-topic relation and - provided if done right (we also have
> somehow orphaned Blends like Debian Junior) - can enhance the quality of
> packages covering a whole topic (see for instance Debian Med advent
> calendar[3] to squash bugs and many others).

Orphaned blends is something we need to figure out how to handle, yes,
and I think that we have them shows that teams are not a panacea.  Teams
require active effort to maintain too

> In short:  If you voted for A above please dive a bit into the topic to
> consider B as an option.  When voting B I think it becomes evident that
> the bug is RC (at least for Buster).

I still don't think it is, not even for buster.  If it's RC, it means
that we fix the bug or one of remove the component from the release
(which I don't think anybody suggests) or that we delay the release
until it's fixed.

I don't think we should do either of those.  Severity is not the same as
priority, we can have super-important bugs which have a low severity.  I
think we should just fix the bug (for Buster) instead.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #711 received at 846002-done@bugs.debian.org (full text, mbox, reply):

From: Margarita Manterola <marga@debian.org>

To: 846002-done@bugs.debian.org

Subject: Closing the bug with the resolution approved in February

Date: Sat, 22 Apr 2017 15:51:16 +0200

Hi,

Let me first say that I'm sorry that we failed to act on this bug 
sooner.
The resolution was voted and approved in early February but we failed to
communicate this by closing this bug.

We acknowledge that most of the contents of the resolution are obsolete 
by
now, but we still wanted to publish this to be able to close this bug 
and
move on.

We thank everyone that was involved in the discussion and hope that we 
can
all work together towards making stretch a great release.

==== RESOLUTION ====

Background

The blends-tasks package was uploaded in April 2016 setting its priority 
to
important.  The result of this change was that the package started 
getting
automatically installed by debootstrap, with the intended effect of 
causing the
list of tasks shipped by the package to be displayed by tasksel in the
debian-installer.

Even though the debian-installer maintainer complained in May 2016 that 
he did
not agree with this approach with regards to including external packages 
in the
default tasksel screen, the important priority remains until today.

In December 2016, changes were made in the tasksel package so that it no 
longer
automatically displays external tasks as part of the debian-installer.

The current state is that chroots created by debootstrap in unstable or 
testing
include the blends-tasks package, although the shipped tasks are not 
getting
displayed during the default installation.

In #846002, the Technical Committee was asked by Holger Levsen to rule 
on the
priority of the blends-tasks package.  In the discussion that followed, 
the
Committee was asked by Ole Streicher to additionally rule on whether the 
Blends
selection should be part of the Debian Stretch installer and who should 
maintain
the list of options displayed to the user in the future.

Using the power of the Technical Committee to make a decision when asked 
to do
so (§6.1.3):

1. We acknowledge that the decision of which tasks to display during
installation falls within the jurisdiction of the debian-installer 
maintainers.

2. In the Committee's opinion the use of important priority is not 
appropriate
for the blends-tasks package according to the definition in the Debian 
policy
(§2.5).  As it was set only as a means to an end, and since it no longer 
does
what was intended, we recommend that this change gets reverted.

3. We encourage the debian-installer maintainers to work together with 
other
teams -including the blends-tasks maintainers- to provide useful and 
popular
package selections through the debian-installer in future releases.

==== END OF RESOLUTION ====

-- 
Regards,
Marga

Send a report that this bug log contains spam.