Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Wed, 18 Nov 2020 17:33:26 +0000 Matthew Vernon <matthew@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
Reply to: