Ian Jackson <ijackson@chiark.greenend.org.uk> writes: > I hereby call for votes on my coupling proposal and the amendments > that have been put. With all 8 votes cast, this CFV on the init system coupling issue has ended in a tie between options "L" and "N". Given my vote on this issue, it should be no surprise that I use my casting vote to declare option "N" is the winner. Therefore: The TC chooses to not pass a resolution at the current time about whether software may require specific init systems. - - - During the TC's IRC meeting some hours ago, Steve Langasek expressed disappointment that I ranked the "L" option below "FD" without providing some explanation. While this had no material effect on the outcome, I agreed to explain my reasoning here. As I stated in my call for votes on the simple question of which init system should be the default for Linux in the jessie release, I'm in favor of Debian supporting multiple init systems. The problem is that I don't believe this is something we should try to preemptively legislate in the TC by imposing a new dependency restriction. It will only happen if those of us who want support for multiple init system in Debian actually do the work required in the context of normal Debian processes and behavior. Some TC members who put the "L" option first express concern that *not* imposing a restriction on dependencies effectively guarantees bad things will happen. Everything I think I know about the Debian project and how we have generally chosen to interact with each other over the last 20 years leads me to disagree. The discussion I've seen since our systemd ballot reinforces my belief that package maintainers try to do the right things, and we should give them the benefit of the doubt. Should the technical decisions they make, including expressing dependencies on some subset of our available init systems, ultimately lead to disagreements worthy of referral to the TC, we can and will deal with them then. Regarding option "A", giving non-binding advice to the project, my feeling was that this option just captured the status quo, and thus wasn't necessary to issue as a TC resolution. However, since I do think option "A" likely captures the broad consensus of the project, I hope it will be seen as well-reasoned input by those who now turn their attention to updating Debian policy around init systems for the jessie release. Bdale
Attachment:
pgpmVuGyainrp.pgp
Description: PGP signature