Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
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
Reply to: