First of all, I would like to thank those who took the time to make proposals. This is a very draining issue, and I thought more than twice about saying something about it publicly at all. I hope that this is useful. My position ----------- I think systemd is better than anything that came before. I think it's good that it has been made the default, and I don't want to do any substantial amount of work to support anything else. I think the majority of our users are better off with a well-integrated system based on systemd. The non-init facilities for declarative configuration, such as support for system users and temporary files, are a big improvement with regards to our traditional maintainer script approach, and we should standardize on strategies like those. However, as with any piece of software, systemd doesn't and won't ever cover all use cases. It should be possible for people to use other init it they choose so, for whatever reason. How well those would work should depend only on the effort of those interested in doing the necessary work. On the one hand, maintainers should not be forced to do work to support non-default configurations. On the other hand, they should not stand in the way of those who want to put the effort in to make non-default setup work. Personally, I commit to take patches for non-systemd support, even if I cannot test them, as long as there is not something clearly wrong or I trust the patch submitter enough to just take their word for it. I also think that the challenge of supporting multiple configurations like this is an interesting engineering challenge, and would like to contribute to make it easier for those want to spend their effort in supporting alternative init systems. For example I considered a few times adding support for testing packages against non-systemd test systems to ci.debian.net, and didn't do it so far just due to lack of time. Anyone who wants to work on that with my guidance can talk to me by mail (debian-ci@l.d.o) or on IRC (#debci). Analysis of the current proposals --------------------------------- In light of the above, I created the following checklist to evaluate the current proposed options: * non-systemd support is not mandatory * maintainers should be free to use non-init facilities provided by systemd * maintainers should be encouraged to take patches for non-systemd support What follows is my evaluation of the current options, based on the above checklist. Matching an item in the checklist provides 1 point, or 0.5 if if the match is not very clear or partial. * Proposal A (Sam): 2 It doesn't say anything about the non-init facilities * Proposal B (Sam): 3 * Proposal D (Ian): 2.5 Even though it allows for the use of the non-init facilities, it imposes a somewhat artificial delay for having them accepted in policy, which in the worst case means at least a 6 month delay even if there is no effort from the communities of alternative init systems to provide an implementation. * Proposal E (Dmitry): 1.5 Makes supporting non-default setups mandatory, and will in practice prevent usage of non-init declarative facilities until there is actually implementations outside of systemd (which can be forever in the worst case). * Proposal F (Martin): 2.5 Errs on the opposite side as proposal D (Ian), relegating non-default init support to wishlist. * Proposal G (Guillem): ? As others have pointed out, this contains no concrete proposal so far. It reads to me like a great preamble to an actual proposal, but without the proposal part. I am still wondering where I want to put my threshold, but so far I am leaning towards ranking any proposal with score 2 or lower below NOTA/FD.
Attachment:
signature.asc
Description: PGP signature