Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello,
On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> First, as a point of order (for which some authoritative guidance from
> the Secretary, CCed, would potentially prove useful): while the
> technical committee is empowered to handle various types of disputes (up
> to and including overruling an individual developer if necessary), I do
> not believe it falls within the scope of the technical committee to
> override a decision already decided by a project-wide GR, or to
> "interpret" the text of a GR issuing a nontechnical policy document in
> ways that may undermine the decision made in that GR and document. Any
> interpretation of the text of the GR would need to be based on the text
> and intent of the GR. (Intent could include discussion at the time, but
> would notably include the text of other options that did not prevail, as
> well as the status quo at the time that motivated a GR to change.)
> Changing that intent would require either another GR, or (per specific
> provisions included in the winning GR option) consensus among the
> project, not a TC ruling.
>
> Concretely, the GR explicitly acted by "Using its power under
> Constitution section 4.1 (5)", which is the power to "Issue, supersede
> and withdraw nontechnical policy documents and statements.". The
> Technical Committee does not have such "nontechnical policy documents
> and statements" within its ambit. Any interpretation of 'what it means
> to "support the efforts of developers" working on support for
> alternative init systems' would thus be an interpretation of such a
> nontechnical policy document.
>
> Thus, I would suggest that the technical committee should decline to
> rule on any matters already decided by the GR. This does not preclude
> the TC from offering advice, or potentially facilitating dispute
> resolution if asked to do so, or even as a *last resort* overruling a
> developer on a specific technical matter (if doing so does not go
> against the GR), but I don't believe it's within the scope of the TC to
> relitigate the GR to mandate support for alternative init systems. Any
> potential ruling here would need to avoid attempting to supersede the
> GR.
I have been thinking about this procedural issue and in the end I think
that it is moot. Let me explain how things seem to me.
In our dispute resolution role, the TC is empowered to decide upon the
two things about the contents of the network-manager package that we
have been asked to decide upon, as a matter of last resort. No-one
disputes that we can do this.
We have also been invited to rule that "Similar init-compatibility
changes should not be blocked by package maintainers unless they are
defective on their own merits". Essentially we are being invited to
generalise the decision that we make about the network-manager package
to say that it would apply to similar cases.
We might decide that the reasons we have for whatever decision we make
about the network-manager package do not generalise, and so we may
decline the invitation to make any more general ruling.
But if we do think the reasons generalise, then we can generalise our
ruling without stepping outside of our dispute resolution role. For
example, we might say "if another CTTE bug was filed about the contents
of a package which was similar to this one in the following respects
... then we would expect to issue the same ruling as we have here,
because we believe that our reasons for this ruling would apply to all
packages which are similar in the previously stated respects."
Clearly we would not want to say anything which we thought contravened
the GR. However, I do not think there is any reason to think that
resolving this dispute would necessarily involve the TC interacting with
the GR in a way that the constitution does not permit. We are being
asked to decide about one package, and being invited to generalise in a
way that falls within the scope of our dispute resolution role.
--
Sean Whitton
Reply to: