Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu
Hi Tollef
On 02.02.2017 19:47, Tollef Fog Heen wrote:
> ]] 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.
This makes it a case where one can ask the TC for a decision, if an
otherwise unresolvable conflict appears. And IMO the TC has the power to
decide here. I have read Sams "vote to override" as "power to override",
and this was where I disagree.
>> 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.
The argument making is better is that (potential) users of the blends
have it easier to find and install the blend. These are, BTW the points
I expected to be discussed here before the voting comes out, and not after.
>> 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).
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.
>> 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.
He wrote "we don't have the vote to override", and this is IMO wrong.
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. I agree
here fully Ian:
Ian Jackson wrote:
> 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.
Best regards
Ole
Reply to: