[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft proposal for resolution process changes



Richard Laager <rlaager@debian.org> writes:
> On 10/5/21 11:04 PM, Russ Allbery wrote:

>> One minor clarification: I was thinking about removing the 2:1
>> *override* requirement, but I don't think we should remove the 2:1
>> *make* requirement.

> Part of the discussion about the TC was that they might deadlock on
> _which_ option to choose, which then needs to go to a GR. If this
> happens, the TC did not make a decision, so the developers are using
> their power to _make_ a decision, not _override_ one. With what you have
> proposed above, the 2:1 supermajority would still apply. That may or may
> not be desirable. But was that your intended result?

Sorry, I didn't provide quite enough context.  My idea was to leave the
casting vote for the TC in place, which means that it's not possible for
the TC to deadlock (this is the point of a casting vote), but then relax
the 2:1 majority requirement to overturn the decision.  That way if the TC
decides something by a very narrow margin, a subsequent GR wouldn't
require a supermajority.

This wouldn't change anything if the TC vote result is further discussion,
since in that case there's no decision to override and, as you point out,
the GR would stay at a 2:1 majority required if the developers wanted to
exercise the powers of the TC.  (In practice, most likely the GR would be
phrased as a statement on issues of the day, which is technically
nonbinding and only requires a simple majority but which everyone is
likely to honor.)

>> There's some weirdness here with maintainer overrides.  I'm not sure if
>> it should be possible to override a maintainer with a simple majority
>> GR.  (By that, I mean I'm literally not sure; I can see arguments
>> either way.)

> Overriding a maintainer by a GR seems like a pretty serious thing. If
> nothing else, it's probably pretty embarrassing. I'd imagine those
> proposing, sponsoring, and voting in favor of such a resolution
> understand that. If we get a majority of developers voting to override,
> that seems sufficient to me (in the context where the 2:1 TC make
> supermajority is already being removed; I'm not necessarily suggesting
> this change standalone).

Yeah, that was exactly the argument I was thinking of in favor of not
making any special rules for overriding a TC decision about a maintainer
override.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>


Reply to: