Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
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)
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)
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)
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)
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)
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)
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)
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)
Hi Cyril,
Just as a reminder for the upcoming alpha that I was trying to do
something about this by adding an extra simplified tasksel promt:
Philip Hands writes:
...
> The menu is now:
>
> --> standard ("${DESKTOP}") desktop <--
> standard server [text-only console & 'ssh' remote access]
> other use cases
I just applied that as a patch to pkgsel and pushed it as pu/simple_tasksel
It just occurred to me that if we made the list of tasks for each choice
be in the template, then it avoids hard-wiring the tasks in the code,
and it should be easier to preseed, so might serve as a customisable menu
for the likes of debian-edu -- I've added that as a subsequent commit,
but that's yet to be tested. I should have time to test that this evening.
The template needs proper anotation for translators.
I think it might well be better to replace 'standard' with 'default'.
BTW as it stands, the server option doesn't bother installing CUPS,
despite that being in the default tasksel set -- That was based on
Colin's comment that task-cups needs a rethink, and is currently a bit
useless.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: December 2016 TC meeting is at 'Thu Dec 22 18:00:00 UTC 2016'
Reminder: this is in two days @18:00 UTC. I've updated the agenda with the current TC topics. Le vendredi, 9 décembre 2016, 13.25:08 h CET Didier 'OdyX' Raboud a écrit : > The December Debian Technical Committee Meeting will happen at > > date -d 'Thu Dec 22 18:00:00 UTC 2016' > in #debian-ctte on irc.debian.org > > The meetings.ics file [0] and the agenda were updated accordingly in git; > please make any necessary changes. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
