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

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Sam Hartman writes ("Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu"):
> My reading of that is that the consensus of the TC is that the D-I team
> should make this decision.

I can see why Ole is frustrated.  I don't think this is a proper
conclusion for the TC to reach.

The request to the TC was for a review of a technical decision.  That
means that the TC ought to review the technical decision, not simply
say that the people who made the decision were the ones who should
make it.

A proper conclusion for the TC to reach might be something like:

  We agree with the D-I team's decision for stretch.

  We want to see this improved in buster.  If no solution
  (satisfactory to all sides) is found within 6 months of buster being
  open, we should be asked to revisit the decision.

Or

  We feel that Phil's proposed new menu question is a good way of
  solving this problem, and that the problem is important enough and
  the risk low enough that we want to see this in stretch.

  Accordingly we ask that the D-I team make arrangements to include
  a new question along the lines which have been suggested.

It seems that the TC prefer the first of these but are unwilling to
come out and say so.

> I'm not sure the TC as a whole has a consistent rationale.

Firstly: it's one thing not to have a consistent rationale.  It's
quite another to duck making decision because you can't agree on a
rationale.

Secondly: if there are competing rationales, let each TC member with a
rationale put their own forward.  The matter can then be resolved by a
vote.

I wish the TC were more willing to have divided votes.  It is not
necessary for the TC to reach internal consensus.  It would be much
better to have a 3:2 TC vote on something like this, than weeks and
months of delay followed by a lack of any concrete decision.

> I believe there are important issues to balance in terms of number of
> prompts, style of user interaction, and risk we're willing to take at
> various points in the release process.  I believe the D-I team has
> traditionally balanced those issues quite well, so I'd delegate this
> decision to them.

I think it is quite wrong for the TC or its members to delegate their
decisonmaking back to the maintainer(s) that the petitioner is in
disagreement with.

If those maintainers cannot explain themselves sufficiently to
convince the TC, then the decision should go against them.

Conversely, if those maintainers _do_ explain themselves sufficiently
to convince the TC (as seems to have happened here), then the TC
should say "we have been convinced of XYZ by the maintainers".

Ian.