Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sam Hartman <hartmans@debian.org>]

>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:

    Russ> We do drop features all the time between stable releases,
    Russ> though, and generally that too is at the maintainer's
    Russ> discretion.  The package maintainer's normal obligation in
    Russ> Debian isn't to keep everything working that previously was
    Russ> working, but to make it obvious when something is incompatible
    Russ> (ideally before it breaks on a given system in a way that's
    Russ> hard to back out of).

Agreed.

    Russ> Often this is done by dropping or
    Russ> renaming packages so that the old package just has no upgrade
    Russ> path, but we handle it in other ways as well (release notes,
    Russ> NEWS.Debian, etc., depending on the severity of the
    Russ> incompatibility).

Agreed.
I think a reasonable way for the TC to handle the init script part of
this bug might be to politely suggest to the maintainer that they
include a note in the release notes.
(Or for a member of the TC to just propose such a note to the release
notes maintainers).
    Russ> I guess the summary of my position on init scripts
    Russ> specifically is that I generally agree with Wouter's framing
    Russ> of two approaches to Debian who want very different things,
    Russ> and I thought (at least for init scripts) we put a range of
    Russ> options on the table from "you must support both approaches"
    Russ> to "we're only going to support one approach," and the option
    Russ> that people chose is "one option is strongly preferred but
    Russ> individual maintainers can support other approaches if they
    Russ> want to and we don't want to make exploration of other
    Russ> approaches impossible."  The implication was that some
    Russ> individual maintainers *won't* want to support other
    Russ> approaches in their individual packages, and that's a decision
    Russ> they get to make, and therefore folks who want to keep
    Russ> sysvinit working should be exploring options that don't
    Russ> require the maintainer incorporate that support (such as a
    Russ> separate package of init scripts or a conversion utility that
    Russ> generates init scripts from unit files).

We are in agreement here.  I guess that's not surprising given how many
times we have discussed this:-)