Bug#727708: init system coupling etc.
Colin Watson writes ("Bug#727708: init system coupling etc."):
> Ian, you said that you don't agree with this amendment. I am guessing
> based on your previous statements that you mainly disagree with the
> force of it, rather than the substance, but I'm cautious of making
> unwarranted inferences or putting words in your mouth. Is this
> accurate? I think it would be helpful if we had as much substantive
> common ground between the ballot options as possible.
OK. I will review it in more detail.
> To start with, I therefore propose the following amendment to L. I
> think it is no weaker except in ways that we would agree were in fact OK
> if we found ourselves needing to rule on them specifically, and this
> addresses points that people have raised here. The first paragraph of
> the "loose coupling" section is replaced by the following:
> In general, software may not require a specific init system to be pid
> 1, although degraded operation is tolerable. The exceptions to this
> are as follows:
> * alternative init system implementations
> * special-use packages such as managers for init systems
> * cooperating groups of packages intended for use with specific init
> provided that these are not themselves required by other software
> whose main purpose is not the operation of a specific init system.
I think this is a good approach. I accept this amendment. Thank you.
> (It took me three goes to draft this in a way I was happy with, so
> perhaps more wordsmithing is needed.)
I'll have a go at that but I don't want to break it.
> I do expect to have some more thoughts on this, and I'd like to ask that
> we not rush to a vote while we're still actively throwing around
> interesting amendments. I've had a cluster of complicated customer bugs
> to deal with at work and have been generally busy in the evenings as
> well, so I've not been able to get all the way through my thinking on
> this. I would rather not have to vote FD again if it can be avoided in
> the discussion period. On the other hand I can understand Ian's wish to
> put a time limit on this rather than it dragging on forever. Would an
> extra week work for everyone? I don't think too much in the way of
> irreversible changes will happen in unstable in that time.
I'm more worried about irreversible changes in the wider world, but
perhaps anything we do now is too late to overcome the "systemd wins
I do see that we are making progress, which I felt we weren't before.
I'm willing to wait. So for the avoidance of any doubt, I'm going to
set a new planned-CFV of 2014-02-20 18:30 UTC.