On Wed, 18 Nov 2020 17:33:26 +0000 Matthew Vernon <matt...@debian.org> wrote: > This bug report relates specifically to bugs in the network-manager > package (#921012, #964139) but has broader implications, particularly > around what it means to "support the efforts of developers"[0] working > on support for alternative init systems (I will talk about sysvinit here > without loss of generality to other non-systemd init systems).
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. That furthermore means that the question asked in the subject ("Should maintainers ...") is much, much broader than any question that should be ruled upon in this issue (if any). The GR answered a closely related question, namely whether maintainers should be *forced* to accept support for alternative init systems, with a definitive "no". While the GR did explicitly state that the "position may evolve as time passes without the need to resort to future general resolutions", that provision would require project consensus in order to evolve such a position. I don't think there's been any indication that consensus has substantively changed in that regard since the time the project passed that GR. In the absence of such consensus, the GR stands as the decision of the project developers. One major aim of the GR (https://www.debian.org/vote/2019/vote_002) was, in large part, to settle with finality many ongoing case-by-case disputes about alternative init system support, and to allow developers to work in peace without having to continuously deal with this disputes of this type; in short, the goal (by proponents of many different positions) was to settle init system questions in one direction or another, in the hopes that the project would abide by the decision once made, rather than expending ongoing energy and attention relitigating it on a case-by-case basis. The GR contained options for requiring ("must"), or even strongly encouraging ("should"/"important"), developers to maintain sysvinit support; those options did not win. The winning option, instead, issued a policy statement that allowed continuing exploration and experimentation with alternative init systems, but specifically stated that "Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work.", and furthermore left it to maintainer discretion ("may", not "should" or "must") whether to include such support in packages. There were certainly more than enough options on the table to allow the developers by way of GR to issue a stronger statement, and the developers declined to do so. And it's even more emphatically clear that "Further Discussion" was not the desired outcome. Per Debian Policy: "Guidelines denoted by may (or optional) are truly optional and adherence is left to the maintainer’s discretion." Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948115 , which implemented the GR in Debian Policy. Any inclusion of work into a package necessitates *some* amount of development and packaging resources by the maintainer of that package. Even if someone else offers to shoulder some of that load, that does not eliminate the maintenance burden; in some cases, it may not even reduce the maintenance burden. (Providing separate packages for sysvinit support that interact with the original package, such as separate packages containing an init script, also adds to the work of the main package's maintainer, but we generally accept that handling interactions between packages and debugging potential issues that may cause is a necessity of maintaining a package. Such an arrangement would have several advantages in terms of reducing the burden of the main package maintainer, including bug triage.) So as a matter of positioning, I don't believe it's appropriate to position this as a maintainer blocking the work of others. If (by way of example) some maintainer were to *actively and gratuitously make it more difficult* for people to work on alternative init support either in a separate package or outside of Debian, in the absence of some appropriate justification (such as breakage caused in the main package), *that* would seem closer to blocking the work of others, and it'd be more reasonable to ask whether that was consistent with the intent of the cooperation encouraged by the GR. But that is not the case here. To summarize: I believe the purpose of the GR was very much to avoid further issues like this, The purpose of the GR was to settle issues like this in general rather than having to deal with them case-by-case. Other non-prevailing outcomes of the GR could have justified a TC issue like this; the prevailing outcome does not. The purpose of the GR was not to lead to technical committee issues being filed in a more-or-less procedurally identical manner to how they would have been filed before the GR, modulo minor wording differences and a citation to the GR. Finally, as a minor procedural note, unless the maintainers of network-manager were to agree to some change here, the TC would require a 3:1 majority to overrule a developer. This assumes that doing so would not contravene the GR. --- Here ends the portion of this mail on procedural matters --- I'd also like to address one other issue here. It would be easy to hypothesize, at this point, that some additional communication (or more verbose communication) from the maintainer might have helped here. However, I would express doubt that any more verbose version of "no" (e.g. a long-form explanation about undesired additional maintenance burden) would have led to any less escalation. I think the situation would still have ended up here, no matter how much time or energy was expended in writing responses. That seems particularly likely given the adversarial NMU directly attempting to override an active package maintainer's decision, which escalated the situation further. (Such adversarial NMUs have occurred in regard to alternative init support in the past, as well.) And I don't think anyone can reasonably suggest that they thought the change was made unintentionally (given that it was explicitly mentioned in the changelog), which makes the NMU a rather hostile escalation. I would ask anyone on the TC who feels that more verbose answers were desirable whether they think a more verbose answer would have had any effect on the outcome or subsequent escalations. Furthermore, I think it's worth taking into account that network-manager is a complex, prominent package, with many expectations placed on it, requiring a substantial amount of effort to maintain. Reducing the number of configurations to deal with is a standard way to control software complexity. (And network-manager has *already* been subject to mandates and expectations in the past that increase the number of configurations and thus the complexity.) The GR encouraged developers to work with each other; it did not *mandate* developers to spend their time and energy supporting alternative init systems, or to spend their time and energy justifying why they are not spending their time and energy. > Both changes are necessary for it to be possible to install > network-manager on a sysvinit system; it is going to be hard to use > Debian without network-manager. I do not think it will be "hard to use Debian without network-manager". (For the sake of clarity, that is not a statement about the usability of alternatives, it's a statement about software installability and capabilities.) On the contrary, there have been extensive arguments on that topic, including two technical committee rulings (681834 and 688772), just to ensure that people can install a system without network-manager, up to and including a GNOME desktop. It's also worth noting that many of those requests came from the same set of people in favor of alternative init support, which makes "alternative init but with network-manager installed" an even smaller subset of users than "alternative init". Given the outcome of those requests (making it possible to install GNOME without network-manager), and the corresponding burdens placed on GNOME and network-manager maintainers, one would hope that it was in fact quite possible to use Debian and even GNOME without network-manager. If Debian were not usable without network-manager, then that would suggest those additional maintenance burdens were imposed unnecessarily, and we should lift them. > Both bugs have sat open for extended periods with no input from the > maintainer; The bug did in fact have input from the maintainer, the day it was filed: it was tagged as wishlist. That seems like a generous response to a report directly asking for the reversion of a change documented in the changelog. It's possible that the maintainer intended it to remain open for documentation purposes, or that the maintainer might have desired to tag it "wontfix" but expected (based on past evidence) that doing so would lead to more rapid escalation. I certainly don't think that is sufficient cause to make an adversarial NMU reverting a maintainer's intentional change. > I'm afraid the effect of this is that the maintainers of this package > are making it impossible for other developers to enable support of > sysvinit. This is not the case. If the maintainers of this package decline to *integrate such support in the package*, that does not close off all paths to providing such support. Other paths to enablement would include separate packages, other network management software, or alternative distributions. I'm sure there are other potential alternatives as well. - Josh Triplett