[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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

Hi Holger,

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

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

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

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

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

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

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

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

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

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

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

Best regards

Ole


Reply to: