[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [draft] Draft text on Init Systems GR



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


Reply to: