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

[Sam Hartman]

Hi, first, you've made the point that you were hoping the TC would help
the blends team and the d-i team work together.
I think that Phil's suggestions for a technical approach are quite good,
and I hope that will move forward in the buster cycle.

With regard to stretch, I honestly don't think there is anything that we
can do that we believe that we should do.
Some of us think Cyril might  being overly conservative in his initial
decision.  I suspect though that we almost all believe that now is way
too late.
Also, I think all the TC members believe that Cyril is the one who
ultimately should have made the is it too late decision for stretch.
I don't think there's more information he could have been given that
would have helped with that.

"You'll get what you want, but not in the time line you want," is a
frustrating outcome.
However, it is the kind of compromise that is often right in this
situation.


> "Ole" == Ole Streicher  writes:

Ole> Yea, I should improve my reading skills for english. This is my
Ole> misunderstanding. However, if this refers to the number of
Ole> votes within TC (right?), counting that would have been part of
Ole> the decision.

The TC has to vote in order to override someone or to use its
constitutional powers.  The TC doesn't need to "vote" in order to decide
to support an existing decision; we can do this by consensus.

We didn't need to hold a vote for me to read the discussion and have
high personal confidence that there would be insufficient votes to
support your position.  marga proposed closing the bug--deciding by
consensus.  No one on the TC .objected to doing that.  That's a fairly
good sign in our processes it is the right decision.  She ended up
deciding to call for a vote.  Based on the results of that vote it seems
fairly clear it would have been reasonable to close the vote by
consensus as well.

Votes are kind of a crappy way to  make such decisions.


signature.asc
Description: PGP signature

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

[Sam Hartman]

I vote A -> FD for the blends-tasks vote.


signature.asc
Description: PGP signature

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

[Cyril Brulebois]

Since I've been asked in an IRC query whether I might be willing to
consider this suggestion:

Philip Hands  (2017-02-03):
> I think this is in part a symptom of mixing up multiple questions in
> one request.
> 
> There seems to be a consensus that the priority change was misguided,
> and that's the thing that is primarily being decided here.
> 
> If I had had more time in the last month, I'd have put some work into
> producing and testing a patch to tasksel to get the blends back in
> without the priority changes.  Sadly I've not had that time, and I
> suspect that we're too late for such things now.
> 
> Personally I think that Cyril's patch to strip out the blends-tasks
> tasks was also a mistake -- hopefully we can now revert both the
> priority change, and that reaction to it.
> 
> I do have time now, so perhaps while we're reverting those changes
> Cyril will be open to persuasion that we could also patch the blends
> back in, and make the menu clearer overall using my early suggestion
> of prefixing the title lines with ===

Sure! Feel free to prepare improvements to be reviewed, merged, and
tested at the beginning of the buster release cycle.

> but I'm certainly not willing to try and force that decision on him
> with my TC stick.

Thank you.


KiBi.


signature.asc
Description: Digital signature

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

[Philip Hands]

Margarita Manterola  writes:

> I call for votes on the following resolution with regards to #846002:
>
>  RESOLUTION 
>
> Background
>
> The blends-tasks package was uploaded in April 2016 setting its priority to
> important.  The result of this change was that the package started getting
> automatically installed by debootstrap, with the intended effect of causing 
> the
> list of tasks shipped by the package to be displayed by tasksel in the
> debian-installer.
>
> Even though the debian-installer maintainer complained in May 2016 that he did
> not agree with this approach with regards to including external packages in 
> the
> default tasksel screen, the important priority remains until today.
>
> In December 2016, changes were made in the tasksel package so that it no 
> longer
> automatically displays external tasks as part of the debian-installer.
>
> The current state is that chroots created by debootstrap in unstable or 
> testing
> include the blends-tasks package, although the shipped tasks are not getting
> displayed during the default installation.
>
> In #846002, the Technical Committee was asked by Holger Levsen to rule on the
> priority of the blends-tasks package.  In the discussion that followed, the
> Committee was asked by Ole Streicher to additionally rule on whether the 
> Blends
> selection should be part of the Debian Stretch installer and who should 
> maintain
> the list of options displayed to the user in the future.
>
> Using the power of the Technical Committee to make a decision when asked to do
> so (§6.1.3):
>
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer 
> maintainers.
>
> 2. In the Committee's opinion the use of important priority is not appropriate
> for the blends-tasks package according to the definition in the Debian policy
> (§2.5).  As it was set only as a means to an end, and since it no longer does
> what was intended, we recommend that this change gets reverted.
>
> 3. We encourage the debian-installer maintainers to work together with other
> teams -including the blends-tasks maintainers- to provide useful and popular
> package selections through the debian-installer in future releases.
>
>  END OF RESOLUTION 
>
> Please vote [A] for acknowledging that this is under the jurisdiction of the
> debian-installer maintainers, and [FD] for Further Discussion.

Since I feel a conflict of interest due to being a D-I team member,
I'll abstain.

If that's unhelpful for some reason, feel free to record my vote as:

  A == FD

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 be priority:standard and not make a mess out of tasksel menu

[Philip Hands]

Ole Streicher  writes:

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

I think this is in part a symptom of mixing up multiple questions in one
request.

There seems to be a consensus that the priority change was misguided,
and that's the thing that is primarily being decided here.

If I had had more time in the last month, I'd have put some work into
producing and testing a patch to tasksel to get the blends back in
without the priority changes.  Sadly I've not had that time, and I
suspect that we're too late for such things now.

Personally I think that Cyril's patch to strip out the blends-tasks
tasks was also a mistake -- hopefully we can now revert both the
priority change, and that reaction to it.

I do have time now, so perhaps while we're reverting those changes Cyril
will be open to persuasion that we could also patch the blends back in,
and make the menu clearer overall using my early suggestion of prefixing
the title lines with ===, but I'm certainly not willing to try and force
that decision on him with my TC stick.

The reason I've been mostly quiet on this subject is that I feel like I
have something of a conflict of interest, also being a (mostly lapsed)
D-I team member, so I've been restricting myself to attempting to
propose possible solutions.

I don't know why anyone else didn't respond to Ian's criticism, but for
my part I didn't think it was even slightly helpful for him to be in
effect pushing me further towards the conflict of interest that I'm
attempting to avoid.

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 be priority:standard and not make a mess out of tasksel menu

[Ole Streicher]

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