On Thu, Nov 14, 2019 at 06:36:53PM +0000, Ian Jackson wrote: > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > * Failing to support non-systemd systems when such support is > available, or offered in the form of patches (or packages), > *should* be treated as a release critical bug. For example: init > scripts *must not* be deleted merely because a systemd unit is > provided instead; patches which contribute support for other init > systems should be filed as bugs with severity `serious'. > > This is intended to provide a lightweight but effective path to > ensuring that reasonable support can be provided to Debian users, > even where the maintainer's priorities lie elsewhere. (Invoking > the Technical Committee about individual patches is not sensible.) > > If the patches are themselves RC-buggy (in the opinion of, > initially, the maintainer, and ultimately the Release Team) then of > course the bug report should be downgraded or closed.
The problem with this is that it, essentially, promotes drive-by patching: someone would like to use a program, but it doesn't come with support for their init system. So they write that support, test it perfunctorily (enough for their use case), and file a bug against the package. The maintainer is now required to include it, because RC. But let's assume there's a critical bug in the support they wrote. Something that during the right phase of the moon could eat data. That's RC, too. Who's supposed to fix that bug now? The package's maintainers? They don't have the setup to test the patch. That seems unfair. The person who filed the data-eating bug? What's to say they even have the skills to do that? That doesn't seem fair, either. The person who initially wrote the support would be ideal, but they are now unavailable. The maintainer is now forced to choose between dropping the support again, resulting in (most likely) another attempt; investing a lot of time in fixing the bug; or leaving it unpatched (and allowing for their users to have their data eaten). I think a better solution is to accept that some maintainers simply won't have the time or inclination to maintain support for non-default init systems, and that such init scripts (or whatever) should therefore be packaged separately from the main package, maintained by someone who actually uses the init system in question. That would also fit well with... > * It is for users and maintainers of non-default init systems, and > the surrounding ecosystem, to test and debug init scripts and other > aspects of non-systemd support. It is also for maintainers of > non-default init systems, and the surrounding community, to decide > what level of compromised functionality is acceptable to users of > non-default init systems. ... this. [...] -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
