Thomas Goirand <tho...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
