Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
I had a great discussion with Mark Hindley about this issue a few months ago. I'd like to summarize what I said in that discussion as input to the TC. But I'd also like to start out by reminding us all what we said in the GR text that we agreed to. As one of the contributors to that text, you might either think I'm in a good or a bad position to interpret it, depending on how you think about such things. I think it's clear I've thought about the problem space somewhat. >However, Debian remains an environment where developers and users can >explore and develop alternate init systems and alternatives to systemd >features. Those interested in exploring such alternatives need to >provide the necessary development and packaging resources to do that >work. Technologies such as elogind that facilitate exploring >alternatives while running software that depends on some systemd >interfaces remain important to Debian. It is important that the >project support the efforts of developers working on such technologies >where there is overlap between these technologies and the rest of the >project, for example by reviewing patches and participating in >discussions in a timely manner. We did not say in that GR that we were interested in supporting ongoing development of sysvinit. Certainly, in my advocacy post for the winning option, I argued that didn't make sense to me. We said only that we were interested in the facilities to allow people to develop alternate init systems. (We did not say we wanted to throw sysvinit away either, but the project did not commit in the GR to interest in sysvinit). We also said: >The Debian project recognizes that systemd service units are the >preferred configuration for describing how to start a daemon/service. That has been further codified in policy as I'll discuss below. I'd think that by the time an alternate init system becomes a plausible general purpose alternative to systemd, it needs to support service units. We also said: Using its power under Constitution section 4.1 (5), 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. So, the consensus can evolve as we watch what people do, and we see how valuable development of alternate init systems is. Personally, I think that an important consideration would be how much actual development of init systems are we seeing vs how much maintenance of existing init systems are we seeing. If we're seeing people who are actively working to solve the problems that made systemd attractive in other ways, writing new code, that sort of thing, I'd hope that we would support that work and get it unblocked. If all we're seeing is maintenance of the same existing init systems, my personal view is that's not what the winning GR option was about. Other things we did not say. We didn't say other init systems would be in bullseye (nor did we say they would not). In my mind, we committed to allowing developers to experiment, not at this time to making any particular init system beyond systemd ready for release. Now, presumably, if someone comes up with some great new init system that solves the problems that makes systemd attractive over sysvinit to a number of users in ways that are different/better, we'd probably like to include it in a release. If sysvinit's users and maintainers can get it ready to be releasable we'd probably like to do that, although I don't think the GR applies to that work so much as the work necessary to allow development to continue. I'll close with my comments to Mark, which touch on how this all interacts with policy as I understand it. I'm mostly going to avoid value judgments and focus on my understanding of what Debian decided in the vote and what our policy is, and try and help you accomplish your goals under that set of constraints. The short of it is that I think we decided that init scripts are purely optionalal. As a consequence, I think that any alternate init system needs to handle service units, or some significant subset of them, to be useful. But see below. I think there are two issues here. I actually think that you have a reasonably good case for escalating the NetworkManager support for the virtual logind packages. In particular, our GR said we were interested in facilitating that work. So, I think it would be reasonable to ask what's going on with that and ask for help trying to work through that. The init script case is more problematic. You don't explain why NetworkManager should have an init script, and the current thinking in Debian policy is that were it a new package, it probably should not. Quoting section 9.3.1 of policy
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
❦ 15 décembre 2020 11:14 GMT, Mark Hindley: >> Okay, great, I now see a clearer argument in favour of dropping the init >> script: enabling the maintainer to preemptively avoid dealing with bugs >> which are likely to generate hostility, rather than just the idea that >> there could be bugs which would generate a lot of technical work for the >> maintainer in which the maintainer does not see much value. > > I am afraid I don't agree with this. > > Hostility is never justified or justifiable and none of us should ever have > to be > subject to it or tolerate it. However, using the avoidance of putative poor > behaviour by others in the future as a justification for a current or past > action > seems a weak argument to me. IMO, the best way to promote the ideals of > tolerance, courtesy, humility and openness is by espousing them in one's > actions > and by doing the right thing. Poor behaviour happened in the past. Almost nothing (literally) is needed to trigger a flamewar around an initscript. https://lists.dyne.org/lurker/message/20171024.145026.a763a9da.en.html -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger)
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Tue 15 Dec 2020 at 11:14AM GMT, Mark Hindley wrote: > Sean and Simon, > > On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote: >> > In the cases where the regression was accidental, ideally, the answer >> > would be someone calmly and politely offering a tested patch, but it >> > sadly seems equally likely to result in hostility, and I think it's >> > reasonable for a maintainer to try to avoid that preemptively by making >> > it clear that the LSB init script is someone else's responsibility. >> > Our volunteers are not automata, and I think maintainers need to be able >> > to set boundaries for their responsibilities to protect their mental state. >> > >> > Similarly, in the case where the dependency is deliberate, I don't >> > think we want the responsibilities of a Debian maintainer to include >> > interceding between angry sysvinit users and upstream. >> >> Okay, great, I now see a clearer argument in favour of dropping the init >> script: enabling the maintainer to preemptively avoid dealing with bugs >> which are likely to generate hostility, rather than just the idea that >> there could be bugs which would generate a lot of technical work for the >> maintainer in which the maintainer does not see much value. > > I am afraid I don't agree with this. > > Hostility is never justified or justifiable and none of us should ever have > to be > subject to it or tolerate it. However, using the avoidance of putative poor > behaviour by others in the future as a justification for a current or past > action > seems a weak argument to me. IMO, the best way to promote the ideals of > tolerance, courtesy, humility and openness is by espousing them in one's > actions > and by doing the right thing. It would not be good to assume that there are never circumstances in which preemptively avoiding hostility by refusing to engage with certain technical options is a reasonable thing for a maintainer to do, but whether it is something the project can accept in this particular case is still in question. -- Sean Whitton signature.asc Description: PGP signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Sean and Simon, On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote: > > In the cases where the regression was accidental, ideally, the answer > > would be someone calmly and politely offering a tested patch, but it > > sadly seems equally likely to result in hostility, and I think it's > > reasonable for a maintainer to try to avoid that preemptively by making > > it clear that the LSB init script is someone else's responsibility. > > Our volunteers are not automata, and I think maintainers need to be able > > to set boundaries for their responsibilities to protect their mental state. > > > > Similarly, in the case where the dependency is deliberate, I don't > > think we want the responsibilities of a Debian maintainer to include > > interceding between angry sysvinit users and upstream. > > Okay, great, I now see a clearer argument in favour of dropping the init > script: enabling the maintainer to preemptively avoid dealing with bugs > which are likely to generate hostility, rather than just the idea that > there could be bugs which would generate a lot of technical work for the > maintainer in which the maintainer does not see much value. I am afraid I don't agree with this. Hostility is never justified or justifiable and none of us should ever have to be subject to it or tolerate it. However, using the avoidance of putative poor behaviour by others in the future as a justification for a current or past action seems a weak argument to me. IMO, the best way to promote the ideals of tolerance, courtesy, humility and openness is by espousing them in one's actions and by doing the right thing. Mark
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Tue, Dec 15, 2020 at 09:51:56AM +, Simon McVittie wrote: > On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote: > > Could I just check if there's a point of common acceptability which both > > sides of this discussion could live with? > > > > libpam-systemd | network-manager-nonsystemd > > Presumably this is an optimized form of what we perhaps conceptually mean: > > default-logind | logind, > systemd-sysv | network-manager-nonsystemd, > > i.e. it needs a logind implementation (preferably our default, which we > happen to know is systemd's), plus either systemd or some glue to support > running the daemon without systemd? > > (I agree that the optimized form is clearer and probably less work for > apt's resolver than the unoptimized form, as long as systemd being our > default is not in doubt - but I'm mentioning the unoptimized form because > I think it might illustrate the motivation better.) Actually, I think the long form is clearer both semantically and in that it clearly separates the functionality of the options. Mark
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote: > Could I just check if there's a point of common acceptability which both > sides of this discussion could live with? > > libpam-systemd | network-manager-nonsystemd Presumably this is an optimized form of what we perhaps conceptually mean: default-logind | logind, systemd-sysv | network-manager-nonsystemd, i.e. it needs a logind implementation (preferably our default, which we happen to know is systemd's), plus either systemd or some glue to support running the daemon without systemd? (I agree that the optimized form is clearer and probably less work for apt's resolver than the unoptimized form, as long as systemd being our default is not in doubt - but I'm mentioning the unoptimized form because I think it might illustrate the motivation better.) smcv
