Hello Simon and others, On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote:
> If we are unable to use particular system services (in this case NM) with > a particular non-default init system without putting extra responsibility > on the maintainers of those system services, then I think that's a > limitation of that init system that its maintainers could usefully > address, and addressing that limitation would certainly be within the > scope of exploring alternatives to systemd. This is a good way to understand the notion of "exploring alternatives to" systemd. Thank you for explaining it. I have not yet seen an argument which convinced me that asking the NM maintainer to keep the init script in the package would actually be putting extra responsibility on that maintainer, and this concerns me. 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. For example, it's been suggested that requiring the NM maintainer to keep the file in the package would mean that the NM maintainer would need to keep a sysvinit system around to test that the init script still works before they could upload a new version of NM. I don't see why there would be any such need. Indeed, I don't think this is how we typically think of the responsibilities of Debian package maintainers. 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. In this case, I don't see how keeping the init script in the package creates any expectations on the NM maintainer beyond applying patches to the init script from those who have the relevant specialised knowledge. A good analogy would be ports. 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. Why would our expectations be any greater in this case? 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. Just as we would accept a maintainer breaking compatibility with a port by reverting a porter's patch if that was the only feasible way to meet a freeze deadline, say. But as has been pointed out, that's not the case we are dealing with here. I would like to see arguments that we would be imposing any extra responsibility on the NM maintainer which do not rely on the idea that a package maintainer is equally responsible for regressions anywhere in their package, or, of course, an argument that I'm misunderstanding what's being implicitly assumed. The dependency issue is more challenging. -- Sean Whitton
signature.asc
Description: PGP signature
