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

Bug#636783: Advice to the TC on overruling maintainers



Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Ian, my apologies for the delay.  I promised you after our dinner
conversation at Debconf that I would try to articulate my concerns with
this GR proposal.  Here's my best stab at it as of today...

>    In the past the Technical Committee have been reluctant to overrule
>    a maintainer unless all the members are absolutely convinced that
>    the maintainer's decision was wrong.

I disagree with this assertion.  I'd be happier if the text focused on
the effect rather than the possible motivation.  That effect might be
that the TC has appeared to be slow to bring such motions to a vote?  If
so, saying that without trying to guess at committee member motivations
would make me happier about this paragraph of preamble.

>    The TC has sought the views of the Developers.  Accordingly, the
>    Developers advise, in their (non-binding) opinion, that:
>
>    ----- GENERAL RESOLUTION OPTION A -----
>
>    The Technical Committee's approach so far has been correct.
>
>    ----- GENERAL RESOLUTION OPTION B -----
>
>    Technical Committee members should be willing to vote to overrule if
>    they feel that the maintainer's decision was wrong; the
>    supermajority requirement is sufficient to guard against overruling
>    in questionable cases.

So, continuing my thought above, the problem with this proposed GR in my
mind is that I already feel willing to vote to overrule if I feel the
maintainer's decision was wrong.  So it's not clear to me that this GR
as worded would "give me any new information" from the Developers.

One reason I can think of that *I* think has caused some such motions to
not be acted on very promptly in the past are honest differences of
opinion about what is right and wrong, that led to a perceived lack of
consensus.  In those cases, maybe just voting on it and gaining a
concrete sense of the position of the TC might have been more effective
in some cases than waiting to try and build a stronger consensus?

The other reason I can think of that some such motions don't get taken
to a vote quickly is when a specific local decision might seem wrong,
but choosing to vote to overrule the maintainer feels like it might do
more harm to the overall project than allowing the maintainer's
apparently bad "local" decision to stand.  I'm having a hard time
articulating a specific example of this, but I have the sense that this
may be one root cause of delay in some of the "who should be the
maintainer of this thing" questions we've faced in the past.  

Where this leaves me is that while I do not object at all to the idea of
using a GR to discover the consensus of Developer opinion on when to
overrule a maintainer, I'm not happy about the assertion of motives in
the preamble, and remain unconvinced that the alternatives as written
would actually lead *me* to an actionable change in personal behavior
regarding voting on TC motions.  That causes me to question the utility
of this proposed GR.

Bdale

Attachment: pgpkNjlWuMRGg.pgp
Description: PGP signature


Reply to: