[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: Call for Votes on init system coupling

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.  


   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


Attachment: pgpmVuGyainrp.pgp
Description: PGP signature

Reply to: