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

[Tollef Fog Heen <tfheen@err.no>]

]] Ole Streicher 

> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
> > If you go back one meeting further, my interpretation is that the consensus of
> > the committee seems to be that ultimately this decision belongs to the
> > installer team.
> > That is, in this case, a number of members on the TC seem to believe
> > that the installer team gets to decide whether/how the installer makes
> > it easy to install blends.
> > 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.
> 
> Hmm, IMO there are two things here: First, in our constitution, the
> installer team has no specific granted rights, apart from being
> maintainers of the relevant packages. This makes the conflict primarily
> a conflict between developers having different opinions about how to
> solve a certain problem. A decision here falls under the rights
> granted to the Technical Team by the Project leader. And I would expect
> that a decision would be made on some technical foundation.

I don't see why this is particularly relevant?  The d-i team is quite
clearly the maintainers of the installer, not just the individual
packages.  This has been the case in the past as well, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367709 for instance.

So, you're asking the installer to change (or, depending on how strong
language one wants to use, subverting the technical mechanisms that are
in place already), and the maintainers are unwilling to accomodate you.

[...]

> We all agree here that the menu is confusing, and that the Blends
> entries don't make it better. The primary question here is however: does
> it really make it so much worse that we can't include it in Stretch?

I think an argument from a position of «this only makes it a little bit
worse» is pretty weak: for me to support overriding the maintainer, you
would have to make it substantially better, not just a little bit worse.

> Compared to the LXQt menu entry addition? At least I doubt that (not
> surprisingly), and I tried to put my arguments here.

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

> It is *not* about just "hey, d-i decided that way. Sorry, we can't do
> anything here". It is about to help us (d-blends and d-i) to sort out
> the technical aspects, to weight them and to come to a solution where
> everyone can agree as much as possible.

I didn't read Sam's response as «we can't do anything», but rather that
we (the TC) are unwilling to override the d-i maintainers.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are