Hello, On Mon 14 Dec 2020 at 10:58AM GMT, Simon McVittie wrote: > On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote: > >> 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. Okay, great, I now see a clearer argument in favour of dropping the init script: enabling the maintainer to preemptively avoid dealing with bugs which are likely to generate hostility, rather than just the idea that there could be bugs which would generate a lot of technical work for the maintainer in which the maintainer does not see much value. It is difficult to think further about this without input from the maintainer as to how much this was a part of his motivation, and what experiences he has had led him to think in that way. >> 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. Let me clarify the things I've said about the expectations we have of maintainers on this point. I don't think we do or should expect anything at all of maintainers with regard to bugs that do not come with patches, or that come with patches for which there is little indication that much thought or testing has gone into them. > 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. Good point. Poor quality bug reports can be pretty easily ignored, but we don't have a comparable approach for maintainers to take with regard to severity wars. >> 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. I don't dispute any of these observations, but would like to note that in each of the cases you've raised there are technical arguments being made on the maintainer's side, rather than concerns about the hostility of interactions. So I am not quite sure of the relevance of the examples. >> 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? I'm not sure it is too helpful to think about hypotheticals like this, to be honest. My point was just that if the circumstances of the init script and the package were different than what they are, we would have different expectations of the maintainer than the situation we actually have, where the script does not seem to be causing any harm. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature