Systemd discussions are back! Wait, don't run away, it is not as bad as it sounds! Noone is seriosly proposing to change the init system back a few weeks before the freeze. In fact none of the proposals so far would have any effect on jessie release. So, please relax and put the pitchforks down.

The discussions are all over a place with long texts ammendments, contra amendments and coounter proposals and proposals to stop all proposals. That makes this whole thing kind of hard to understand in a quick glance, but I think this email from Lucas has the best summary of the proposed options (Ian does disagree with that).

The whole purpose (as far as I understand) of the GR is to make sure that our users would be able to switch init systems on their installations with no more pain than in the previous releases.

To restate (without all the technicalities and exceptions and pesky details) the proposals are:

1. Ians proposal would make failing to support running with alternative init systems a bug. The severity of the bug would be the same as if the package would fail to work for all users in the same way as it fails to work with, for example, sysvinit running as PID 1. Thus if the package can not work at all with sysvinit as PID 1 that would make it a "grave" bug.
2. Lucas proposal would basically do the same, but limit the bug severity at no more than "normal".
3. Other proposals would basically do nothing but restate the already known fact that maintainers are free to disregard upstream wishes in their packaging, especially to support our users better.

I, personally, would like to see Ians GR pass (after amending 'some oner init system' to 'sysvinit' and the clarification that this, obviosly, does not impact jessie). I see no point in even voting for any other proposed GR - it should be perfectly clear to everyone that Debian maintainers may disregard upstream wishes in their packaging, especially to serve our users better (like by splitting logind from systemd). And it should be perfectly clear to everyone that it is a bug for a piece of software to only be runnable under one init system or one window manager or one start menu app or just one implementation of any other generic system service with multiple implementations and a common subset of functionality. There should not even be a discussion about it - it is a bug. Now should such bug scale all the way to release critical levels - that is worthy a GR vote. Which is exactly what Ian proposed.

P.S. Please take care to read preseeding proposals and discussions before seconding things. I do not understand why people would second several GR counter-proposals that did not actually deal with the original issue and sometimes simply restated status quo. Please care what you propose and what you second.

P.P.S. I might even suggest tightening the "common init system API" down to nothing at all - just declare that all software should be able to work with "init=/bin/sh" where you should be able to simply manually start up all dependencies and the software itself and have it work without even starting an init system. Technically that is almost the same as requiring it to work with sysvinit, however.