On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton <spwhit...@spwhitton.name> wrote: > 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. [...] > 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.
(I agree with this paragraph, in case there was any doubt about that.) > 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. It would certainly be *possible* for the TC to suggest that it would systematically rule in favor of, to use these two issues as examples, including init scripts and alternative dependencies despite the maintainer not wishing to maintain them. What I'm suggesting is that, given that the slate of GR options included possibilities that would have required maintainers to do so by policy, and the developers declined to enact such a policy, it would be *especially* unfortunate if the common practice became to either systematically escalate to the TC or use the threat of such to effectively enforce a different policy. The GR encouraged people on all sides to collaborate in this area, not to pick a side and do everything possible to undermine the other side. It seems as though the current path thus far has been to present one option, and when that option was declined, seek enforcement from the TC. I don't feel like people have asked the question, let alone answered it, of how alternative init systems could be supported with a reduced burden on maintainers; rather, the focus seems to remain on arguing that such a burden is either nonexistent or should be forced on maintainers. I trust the current TC to evaluate the issue fairly. I wanted to ensure that the TC had available some additional considerations besides those presented and highlighted in the original framing of this issue. Between my original mail and this partial summary, I've now done so, and in the interests of keeping this discussion manageable, I'm *hoping* that it'll be possible to minimize the restatement of previous arguments and just keep things to *new* information that has not previously been presented. I don't think people arguing at each other will provide further help to the TC.
