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