Bug#746715: the foreseeable outcome of the TC vote on init systems

[Josh Triplett <josh@joshtriplett.org>]

Ian Jackson wrote:
> Ian Jackson writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"):
> > I do think there is still something for the TC to do here.  As Andi
> > writes, the TC failed to clarify that we expect people to continue to
> > support multiple init systems.  Evidently this was a mistake.  It is
> > not too late to rectify it.
> ...
> >     A maintainer recently peremptorily removed support for upstart
> >     from one of their packages.
> > 
> >     The Technical Committee thanks Steve Langasek for bringing this
> >     matter to our attention.  We are pleased that the maintainer has
> >     agreed to revert the disputed change.
> > 
> >     For the record, the TC expects maintainers to continue to support
> >     the multiple available init systems in Debian.  That includes
> >     merging reasonable contributions, and not reverting existing
> >     support without a compelling reason.
> > 
> > I deliberately don't name or criticise the maintainer.  I'm open to
> > suggestions for improvements to the wording, but I think what I have
> > in the final paragraph should be uncontroversial within the TC.
> 
> Apparently it is controversial within the TC to say even (some)
> uncontroversial things.

>From what I can see in the thread, it seems like folks viewed a
statement as unnecessary given how rapidly the situation that prompted
this got resolved without the need for TC action.  It also seems
completely understandable, in light of Ubuntu's in-progress migration
from upstart to systemd, that a Debian maintainer could see upstart
support as unlikely to remain useful.  In that regard, I think it would
help greatly if the upstart maintainers in Debian (rather than the TC)
could post an announcement regarding the long-term plans for upstart in
Debian in light of Ubuntu's stated long-term plans.

Also, the last paragraph of the statement proposed above does in fact
seem controversial; "expects maintainers to continue to support" is a
much stronger statement than expecting maintainers to merge reasonable
contributions and not drop such contributions without reason.  The
latter seems completely reasonable, albeit a somewhat redundant
statement of how package maintenance normally works in Debian.  The
former, "expects maintainers to continue to support", assumes such
support already exists in all cases, and seems to inherently disregard
and disparage packages that specifically make use of the features of one
or more init systems and depend on those init systems.

Nothing forces a maintainer to add support for any particular init
system; it seems reasonable to expect a maintainer to incorporate
reasonable changes for another init system, and not intentionally break
or drop those changes if they have a reasonable maintenance burden
(which holds especially true if those changes have an active
maintainer), but the proposed statement as written could easily be used
as a hammer against maintainers of packages that support one init system
and have received no reasonable contributions to support others.

> Nevertheless, I intend to press for a resolution along these lines.
> 
> Unless someone comes up with some wording which I consider an
> improvement I will formally propose the above, and eventually take it
> to a vote.  I'll give a period of at least 72h for opponents to
> propose amendments.

Not a member of the TC, but nonetheless suggesting the following, in the
hopes that a TC member will second it:

First, one change that I'd like to see accepted as an amendment to the
above, since it doesn't change the stated intent of causing the TC to
make a statement in support of multiple init systems:

- Dropping the first two paragraphs that make this statement come across
  as reactionary to a non-specific incident, and instead tweak the third
  paragraph more along the lines of the statements Ian proposed as part
  of the previous TC decision on init systems.  Posting a reactionary
  statement in response to an incident that got successfully resolved
  via normal processes seems like a poor way of encouraging those normal
  processes.

Second, a change I don't expect to see accepted as an amendment, since
it tones down the statement in support of multiple init systems to just
a reminder about how our existing maintenance processes *already* work
for any non-required feature people care about:

- Adjusting the last paragraph to be more precise about expectations
  (and non-expectations) from package maintainers: "The TC expects
  package maintainers to accept and maintain reasonable contributions
  adding support for multiple init systems, both default and
  non-default.  Packages that already have functional support for
  multiple init systems should not drop that support without a
  compelling reason."

Finally, in the interests of having an alternative to the current
proposal other than "FD", to distinguish between "we should discuss this
further" and "there's nothing that needs further discussion here", there
should be an option on the resulting ballot to *not* make a statement at
this time:

- "The Technical Committee believes that Debian's normal collaborative
  processes can successfully handle the ongoing maintenance and
  contribution of support for multiple init systems, and does not have a
  further statement to make about support for multiple init systems at
  this time."

(Wordsmithing welcome on all three of the above; they're intended as
roughly delineated positions, not rigid ones.)

- Josh Triplett