I'm going to make a similar point to Sam's but in a slightly different way that hopefully will help. (Also, I apologize for sounding rather too absolute in my initial response to your proposal. There were better ways of phrasing my concerns.)
Guillem Jover <[email protected]> writes: > I'm actually not sure how the other options can be seen as resolving the > root issue at hand. I see what they are trying to do, but I don't think > they are framing it correctly. They are all approaching the problem from > the symptoms, by either trying to go into details on how to integrate > specific stuff, or on how to behave. This all feels like they assume > that people would not respect the spirit of a decision, and to combat > bad faith they need to be very specific on details? But if we'd assume > people are going to be acting in bad faith, then no amount of details > and specifics would fix this, and IMO it can make it worse, as it gives > a list of things to be looking loop holes into and questioning > legalities all over. I think this is a recipe for disaster, and I also > find that type of framing a bit depressing. This isn't how I think about the options. I don't think people are going to behave in bad faith. Rather, I think the problem is what Sam alluded to: General statements of principle are more open to interpretation than their authors think that they are. With full respect and credit to those who have different goals for this GR, I personally am largely uninterested in the project making a general statement of principles about integrating technology. To be frank, I'm dubious of such statements. I don't think they're always helpful. I also think the principles of Debian developers are highly diverse (which is great), and perhaps our goal should not be to try to get everyone in Debian to align on the same principles, but instead to make practical decisions that can be supported from a variety of principles. The problem I want to solve is that we need to make three work-blocking decisions: 1. Is every package that wants to start a service always, sometimes, or never required to include an init script? If they are, at what bug severity and with what consequences if this is not done? 2. Are package maintainers allowed to use systemd-exclusive facilities that would improve system integration for systemd users or improve other goals (such as security) at the cost of compatibility with other init systems? If so, what process should we use for adopting those facilities? 3. How much effort is the project committing to undertaking to incorporate alternatives to major systemd ecosystem components (such as elogind) that are not drop-in replacements, either due to their own implementation limitations or because our dependency system or other tools makes drop-in replacement difficult? As one of the Policy editors, I am primarily concerned with 1 and 2. I'm only an interested bystander for 3 (ideally Policy should have something to say here, but we haven't gotten there). I see huge value in the project making those decisions without regard to whether the project can agree on principles underlying those decisions. I don't want to argue about interpretation of some general, non-specific statement. I want the project to make some decisions. I believe that we have already exhausted or ruled out other project mechanisms to make these three critical technical decisions (Policy process, debian-devel discussion, and the Technical Committee). I think delegatd teams and the Technical Committee are (correctly!) unwilling to speak for the project on these closely-divided and highly divisive issues. Debian is constituted as a democracy of developers. The project makes technical decisions of last resort via vote. We've put off this decision as long as we reasonably can, we've tried for five years to let the discussion calm down and to find some alternative method of reaching consensus, we've waited to see if some nonconfrontational approach will evolve, and people are still sniping at each other. Meanwhile, work that people want to do in Debian, whether that be better support for non-systemd systems or taking advantage of valuable systemd features such as ProtectSystem or DynamicUser, is often blocked on these decisions with no clear prospect for resolution or unblocking. You may have noticed in these discussions that I'm not talking about my own opinion about what the decision could be. I have an opinion, but I've spent enough energy attempting to convince other people of my opinions on init systems for one lifetime. On this vote, I'm on team "make a decision already, whatever that decision is," and the position I'm advocating here is please do not kick the can even farther down the road. Towards that end, here are the specific implications of the various options that I anticipate for Policy. Please note that this is just my personal opinion as one of the Policy editors. Sean doubtless has his own opinion and may not agree with me, and we'll sort that out in open discussion. This is just my starting position. I'm commenting only on questions 1 and 2 because I don't understand the intricacies of question 3 well enough to comment, and because I think it's currently largely outside the scope of Policy. Choice F: 1. Policy will require packages that want to start services include either a systemd unit or an init script and will recommend a systemd unit. Support for starting services under other init systems will not be required or recommended, but of course may be included if the maintainer wishes. 2. Package maintainers are allowed to depend on any systemd facility that they believe is desirable (and, obviously, is supported by the systemd maintainers) and that doesn't contradict other requirements in Policy. The Policy editors and anyone else who is interested will start looking at systemd facilities that may be better ways to do things Policy currently requires be done some other way and will start changing Policy to allow or require the systemd facility be used instead when appropriate and when there are clear benefits. Choice B: 1. Same as Choice F. 2. Same as Choice F. (I think the difference between choice B and choice F is largely about question 3.) Choice A: 1. Policy will recommend that all packages include init scripts, at least until such time as the non-systemd community reaches consensus on some other format for starting services (if that ever happens). In practice, this will likely mean that Policy will recommend including both an init script and a systemd unit, because there are various options that can only be enabled on systemd systems via a unit file and that I can't in good conscience support Policy not recommending (such as ProtectSystem). 2. Package maintainers of non-systemd-specific software may not depend on systemd-specific facilities unless at least sysvinit (currently; in the future, possibly the major alternative init system should the community converge on another one) also implements that feature. Choice D: 1. Same as Choice A. 2. Policy editors and other interested parties will begin looking at systemd facilities of value and writing Policy specifications for them following the rules laid out in the proposal. There will be a grace period of at least six months and no more than twelve months from the point of agreement on the facility to the point at which package maintainers are allowed to use those facilities. Choice E: 1. Policy will require that all packages include init scripts, at least until such time as the non-systemd community reaches consensus on some other format for starting services (if that ever happens). As with Choice A, Policy will probably recommend that packages also include a systemd unit. 2. Same as Choice A. Choice G: 1. Policy will continue to be effectively deadlocked here, and thus will retain the current (confusingly-worded) rule that all packages must contain init scripts. I personally will likely be sufficiently frustrated by the lack of clear guidance that I'll steer clear of init-related parts of Policy and not invest further resources in reviewing language or trying to find consensus for any changes. 2. Policy will adopt only changes that can reach consenus, which in practice likely means the same as Choice A except with significantly increased frustration. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
