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

[Philip Hands]

Cyril Brulebois  writes:

> Philip Hands  (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
Description: PGP signature

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

[Cyril Brulebois]

Philip Hands  (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
Description: Digital signature

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

[Philip Hands]

Cyril Brulebois  writes:

> Raphael Hertzog  (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
Description: PGP signature

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

[Cyril Brulebois]

Raphael Hertzog  (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
Description: Digital signature

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

[Raphael Hertzog]

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/

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

[Philip Hands]

Philip Hands  writes:

> Steve McIntyre  writes:
>
>> On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>>>Raphael Hertzog  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=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
Description: PGP signature

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

[Philip Hands]

Steve McIntyre  writes:

> On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>>Raphael Hertzog  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 

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

[Steve McIntyre]

On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote:
>Raphael Hertzog  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.st...@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

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

[Philip Hands]

Raphael Hertzog  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
Description: PGP signature

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

[Cyril Brulebois]

Hi,

Philip Hands  (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  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
Description: Digital signature

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

[Raphael Hertzog]

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/

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

[Ole Streicher]

Hi Sam,

On 21.12.2016 16:10, Sam Hartman wrote:
>> "Ole" == Ole Streicher  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

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

[Sam Hartman]

> "Ole" == Ole Streicher  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.

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

[Ole Streicher]

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

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

[Cyril Brulebois]

Ole Streicher  (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
Description: Digital signature

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

[Holger Levsen]

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
Description: Digital signature

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

[Ole Streicher]

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

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

[Ole Streicher]

Hi Cyril,

On 20.12.2016 15:01, Cyril Brulebois wrote:
> Ole Streicher  (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

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

[Steve McIntyre]

On Tue, Dec 20, 2016 at 03:01:50PM +0100, Cyril Brulebois wrote:
>
>Ole Streicher  (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.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

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

[Cyril Brulebois]

Hi,

Ole Streicher  (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
Description: Digital signature

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

[Ole Streicher]

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

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

[Cyril Brulebois]

Hi,

Philip Hands  (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
Description: Digital signature

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

[Thomas Hochstein]

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

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

[Tollef Fog Heen]

]] 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

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

[Philip Hands]

Ian Jackson <ijack...@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
Description: PGP signature

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

[Ian Jackson]

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 <ijack...@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.

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

[Wouter Verhelst]

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

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

[Ole Streicher]

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

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

[Philip Hands]

Ole Streicher  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
Description: PGP signature

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

[Ole Streicher]

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

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

[Philip Hands]

Ole Streicher  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
Description: PGP signature

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

[Ole Streicher]

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

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

[Philip Hands]

Raphael Hertzog  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
Description: PGP signature

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

[Christian PERRIER]

Quoting Raphael Hertzog (hert...@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
Description: PGP signature

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

[Holger Levsen]

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
Description: Digital signature

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

[Cyril Brulebois]

Hi Raphaël and all,

Raphael Hertzog  (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
Description: Digital signature

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

[Ole Streicher]

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

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

[Raphael Hertzog]

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/

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

[Philip Hands]

Ole Streicher  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
Description: PGP signature

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

[Andreas Tille]

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

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

[Ole Streicher]

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

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

[Wouter Verhelst]

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

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

[Ian Jackson]

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 <ijack...@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.

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

[Philip Hands]

Ole Streicher  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:
>> 
>> blend=med
>> 
>> 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
Description: PGP signature

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

[Philip Hands]

Ole Streicher  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
Description: PGP signature

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

[Ole Streicher]

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

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

[Ole Streicher]

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:
> 
> blend=med
> 
> 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

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

[Ole Streicher]

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

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

[Philip Hands]

Andreas Tille  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:

  blend=med

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
Description: PGP signature

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

[Andreas Tille]

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

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

[Andreas Tille]

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

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

[Steve McIntyre]

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.st...@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

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

[Tollef Fog Heen]

]] 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

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

[Sam Hartman]

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.

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

[Bdale Garbee]

Philip Hands  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
Description: PGP signature

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

[Andreas Tille]

[ 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

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

[Andreas Tille]

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 
Date: Mon, 5 Dec 2016 12:46:22 +

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


From: Ole Streicher 
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

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

[Didier 'OdyX' Raboud]

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
Description: This is a digitally signed message part.

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

[Ole Streicher]

On 06.12.2016 12:02, Philip Hands wrote:
> Ole Streicher  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

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

[Philip Hands]

Ole Streicher  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
Description: PGP signature

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

[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.

> 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

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

[Holger Levsen]

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
Description: Digital signature

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

[Philip Hands]

Sam Hartman  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
Description: PGP signature

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

[Holger Levsen]

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
Description: Digital signature

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

[Andreas Tille]

Hi Holger,

On Mon, Dec 05, 2016 at 08:07:19PM +, 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

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

[Ole Streicher]

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

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

[Don Armstrong]

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

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

[Don Armstrong]

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

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

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #846002 [tech-ctte] blends-tasks must not be priority:important
Bug 846002 cloned as bug 847132
> reassign -2 src:blends
Bug #847132 [tech-ctte] blends-tasks must not be priority:important
Bug reassigned from package 'tech-ctte' to 'src:blends'.
Ignoring request to alter found versions of bug #847132 to the same values 
previously set
Ignoring request to alter fixed versions of bug #847132 to the same values 
previously set
> block -2 by -1
Bug #847132 [src:blends] blends-tasks must not be priority:important
847132 was not blocked by any bugs.
847132 was not blocking any bugs.
Added blocking bug(s) of 847132: 846002

-- 
846002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002
847132: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847132
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Holger Levsen]

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
Description: Digital signature