Re: BITS from the DPL For September/October 2019
Thomas Goirand <thomas@goirand.fr> writes:
> The last time we've had a GR on init systems, the general response was
> that we don't want to vote, and we preferred the TC to decide.
I don't think the core questions here are technical questions. I think
they're more fundamental questions of project direction and questions
about what burden we want to put on ourselves as package maintainers in
order to support a variety of init systems. This seems like a good set of
issues to resolve democratically, at least for lack of a better
alternative. Resolution by TC on this issue seems likely to lead to lead
to challenges to the TC's impartiality or legitimacy. That's really not
very much fun to go through when you're on the TC.
We've now had several years of essentially declining to make a decision
and trying to see if the project can muddle through, and while I feel
somewhat vindicated by the fact that this didn't immediately fall apart
and has sort of worked, I think it's becoming increasingly untenable. We
now have contributors who are far-removed from the original debate and who
may have only used a systemd-based Debian system and we do not have clear
project consensus that sysvinit support is mandatory in new packages, so
the support is starting to bitrot, and given the lack of clear project
guidance, no one is clearly empowered to prevent it from bitrotting.
The current Policy text is a mess, and everything it says on the topic is
essentially accidental, being left over from text that was added to
clarify how to support upstart, before the TC decision on the default init
system. It's unclear what requirements Policy should actually set on
packages that want to ship daemons, and any attempt to hammer that out is
likely to be contentious and have great difficulty reaching consensus.
I think it was the right thing to do to refuse to make a clear long-term
decision at the time, when the project had just gone through a bruising
and awful argument. Now that we have some distance and have seen how the
ecosystem has subsequently evolved, I think it's time to circle back and,
hopefully with more accumulated wisdom, a bit of emotional distance, and a
bit more calm, make the deferred decision.
If we're really going to continue to fully support sysvinit, we should
commit to doing so clearly and empower people to test that support and
report bugs of appropriate severity (and also to create a stronger
incentive for making that support easier to achieve). If we're not, we
should unambiguously free people from doing additional work that they
don't want to do and can't test easily, and also more clearly communicate
the project's intentions so that our partners like Devuan can make
informed decisions about how to proceed. The simmering uncertainty and
low-level tension of not having a decision eventually becomes its own
problem.
A GR may not be the best mechanism to make that decision, but I'm not sure
what method would be better.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: