Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
> The dependency issue is more challenging.
As I said earlier in the thread, if we don't want to overrule on the
logind dependency, then I don't think overruling on the init script
would make any sense (whereas overruling on the logind dependency but
not the init script maybe would - that would effectively mean we were
asking sysvinit users who want to use NM to find a way to maintain an
init script out-of-band).
However, I think it's still worth talking about the init script, because
most of what I'm saying is non-NM-specific.
> Participants in the thread who have argued on that side of the
> discussion seem to implicitly rely on the idea that a package maintainer
> is responsible for applying an equally high level of quality assurance
> to every file or feature in their package, as that which they would
> apply to its most basic or flagship features.
Ordinarily, perhaps yes. However, for whatever reason, people are
particularly emotionally attached to particular init systems (or perhaps
to the absence of systemd). We can see this here already: I don't think a
dependency on a particular httpd or email server would have been brought
to the technical committee asking for a maintainer to be overruled,
and it seems unlikely to have had participants describing a maintainer
declining an NMU as an outrage.
If NM's LSB init script was present, but stopped working - perhaps
because upstream deliberately made more use of systemd facilities, or
because upstream accidentally relied on systemd facilities due to none of
the upstream developers using anything else, or because the command-line
syntax changed and the upstream-provided systemd unit was updated but the
downstream init script wasn't - what do we expect to happen?
In the cases where the regression was accidental, ideally, the answer
would be someone calmly and politely offering a tested patch, but it
sadly seems equally likely to result in hostility, and I think it's
reasonable for a maintainer to try to avoid that preemptively by making
it clear that the LSB init script is someone else's responsibility.
Our volunteers are not automata, and I think maintainers need to be able
to set boundaries for their responsibilities to protect their mental state.
Similarly, in the case where the dependency is deliberate, I don't
think we want the responsibilities of a Debian maintainer to include
interceding between angry sysvinit users and upstream.
> We want maintainers to
> perform testing which is adequate to ensure that the core features of a
> package won't regress if they upload a new version, but we do not take
> maintainers to be responsible for testing every optional feature and we
> accept that such things might be temporarily broken until someone other
> than the maintainer can provide a patch.
I think perhaps you have higher expectations of bug reporters than I do
- perhaps because I'm involved in triaging/maintenance for user-facing
desktop packages. Bug reports are not always accompanied by patches,
and somewhat frequently come with the implication (or even an explicit
demand) that the maintainer must stop whatever it is they are doing and
fix the bug immediately.
In the case of init system integration, it isn't completely clear what
the severity of "NM doesn't work with sysvinit" would be, and proponents
of sysvinit might argue for critical because losing network connectivity
effectively breaks the whole system in some cases, or serious because
the package should be able to work without its non-mandatory dependencies.
RC bugs are one of the few places where the project puts specific
expectations on maintainers.
Conversely, there's also a reasonable argument for important, normal
or wishlist, because sysvinit is one of multiple options - but getting
into an argument over bug severity is still getting into an argument,
and for developers who don't enjoy conflict, takes significant "spoons"
to deal with.
For what it's worth, if we look at the results of GR 2019-002, and
ignore the winning option B because it did not specify the severity
of bugs about requiring a non-default init, we can see that option F
(non-default init support is wishlist) was voted ahead of options A
(non-default init support is important), D and H (non-default init support
is RC if a patch is available), and E (LSB init scripts are required,
presumably meaning RC). The design of our voting system is (meant to be)
such that we can draw conclusions from how options other than the winning
option were ranked, not just from the winning option vs. all the rest.
> We do not expect maintainers to maintain
> an environment to test their package on ports architectures before
> uploading, but we do expect them to apply patches provided by porters
> who discover regressions.
I don't think that's completely true. If a maintainer considers a
proposed patch to be unsuitable, we normally accept their judgement;
and if a proposed patch for ports is not upstreamable, we normally
accept the maintainer's judgement as to whether the technical debt of
having non-upstreamable patches is a more important consideration than
inability to build or work on ports architectures.
We also don't generally try to overrule maintainers who mark packages as
being Linux-specific, or otherwise specific to particular architectures.
> Of course, if the script became seriously broken and was getting in the
> way of a release or something like that, we would typically see it as
> within the maintainer's prerogative to remove it.
That would mean that people who refuse to use systemd have to find an
alternative on short notice, which seems at least arguably worse for
them than knowing ahead of time that this particular package is not
going to be available to them?
smcv
Reply to: