Tl;DR: I think this option is strictly better than the current hartmans1. If you disagree please let me know. Especially if you want to see the current hartmans1 on the ballot let me know. I'd like to replace hartmans1 with this option. I've attempted to revise choice hartmans1 along the lines of Dmitry's proposal. This is consistent with the spirit of what I proposed earlier, but I hope addresses Ian's objections and makes it clear that the difference is the severity of the bug. Based on Simon's comments I think it is relatively important to have this option on the ballot. If it is not on the ballot we force people who find the RC issue important to make a choice; some of them get pushed towards Dmitry's options and some of them get pushed towards other options. I suspect we could argue over which positions that most benefits, but it seems to me like such strategic culling of options is not in the project's interest. I'm still open to arguments that the option should be removed from the ballot, but I'm much more inclined to keep it than I was this morning. ---------------------------------------- Choice hartmans1A: Init deversity is Important and NMUable The project issues the following statement describing our current position on Init systems, Init system diversity, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus. Being able to run Debian systems with init systems other than systemd continues to be something that the project values. Every package should work with pid1 != systemd, unless it was designed by upstream to work exclusively with systemd and no support for running without systemd is available. It is a important bug (although not a serious one) when packages should work without systemd but they do not. Developers may perform non-maintainer uploads to fix these bugs. Software is not to be considered to be designed by upstream to work exclusively with systemd merely because upstream does not provide, and/or will not accept, an init script. modification of Policy to adopt systemd facilities instead of existing approaches is discouraged unless an equivalent implementation of that facility is available for other init systems. ----------------------------------------
Attachment:
signature.asc
Description: PGP signature