Re: [draft] Draft text on Init Systems GR
Wouter Verhelst <wouter@debian.org> writes:
> 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.
While I agree that Ian's wording doesn't say this explicitly, my
assumption is that the maintainer could remove the sysvinit support if it
is itself RC-buggy and the maintainer wasn't willing to fix it, by analogy
to the case in the last paragraph above. Obviously, to be consistent with
the rest of Ian's proposed wording, this should be done only as a last
resort and after seeking help from the sysvinit community to fix the bug
properly.
That being said, the other point that Ian is making is that it's up to the
sysvinit community to decide whether an RC bug that only affects the
sysvinit community is actually RC. So in this case the release
criticality of the bug would be decided by the same community which is on
the hook to fix it, which seems fair.
> 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'm not sure why another attempt is a poor outcome.
> 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.
It's not clear that this is technically feasible, so I'm not sure that it
makes sense to mandate this solution in a GR.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: