Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu
Hi Tollef,
On 02.02.2017 21:29, Tollef Fog Heen wrote:
> ]] Ole Streicher
>>>> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
>>>>> If they don't want to do that for stretch, that's a decision within
>>>>> their pervue that we clearly don't have the votes to override.
>> I have read Sams "vote to override" as "power to override",
>> and this was where I disagree.
>
> My mind-reading skills are not great, but I don't think that was what
> Sam meant. He wrote «votes to override» (note the plural), which, to
> me, means «there are not enough people who agree that this should be
> overridden», not «we don't have the power to override this (regardless
> of the number of votes».
Yea, I should improve my reading skills for english. This is my
misunderstanding. However, if this refers to the number of votes within
TC (right?), counting that would have been part of the decision.
>>> Personally, I don't see the big point of adding LXQt to the list, but on
>>> the other hand, I don't think the tech committee should micromanage (and
>>> arguably, we're not allowed to, depending on whether that'd be «detailed
>>> design work» or not).
>>
>> An argument of d-i is: We know that it is already pretty confusing now,
>> but it is a compromise, and we don't want to make it worse. Adding LXQt
>> *makes* it worse, so it invalidates this argument.
>
> Not really. It weakens it, but it doesn't invalidate it.
I am not sure if it is worth to discuss this further (at least unless
the initiated vote fails). Again, this discussion could have been useful
before a voting, and I expected exactly that to happen here before the
voting starts.
It should have been part of the way you come to a conclusion, and maybe
even to convince me. Or maybe KiBi.
>> The TC has the power to decide here, and you were asked to do so. If you
>> think that d-i took the right decision, you should decide so (and then
>> you don't need to use your power), but not just let them decide.
>
> That's what the current ballot effectively says. We're refusing to
> override the d-i team.
No, this is a difference. I asked to decide whether the blends menu
should go into the installer (in one or the other way), questioning the
decision of d-i, and you (resp. those who select "A > FD") delegate the
question back to d-i, without having a detailed technical discussion.
Ian made the point here, IMO, and I wonder a bit why his critics remains
unanswered.
Just have a look into the voting proposal:
Margarita Manterola writes:
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer maintainers.
There is no discussion at all whether the benefits of the blends menu
overtake the disadvantaged of the current solution. This is just the
formal common statement that one should not override it from outside; so
you certainly do not accept other (non-d-i) packages to put a menu there
(which is then specified in the second item, regarding the solution we
made here).
This however just answer the question of who usually shall decide on it.
I does *not* answer the specific question, whether the blends menu
should be in the installer (since the TC could override the d-i decision
even if it acknowledges that they should decide). The answer to the
latter is just given by *not* taking a decision, by *not* discussing
this aspect here, even if asked so. IMO this ignores the goal of the TC
(again, see Ians argument; he had a good wording for that).
Best regards
Ole
Reply to: