This is a reply to multiple messages. I know it's long, I don't see a way to avoid that. Search for lines of equal signs (=) to split issues I'm replying to.
Working with Downstreams ======================== So, a couple of people have commented on the commitment to work with downstreams in choice 2 and 3. Here's what that commitment means to me. It means that we'll work with derivatives to figure out where the boundary is between their derivative and Debian. We (particularly the DPL) will be responsive to questions about where that boundary is. When it is not obvious, that may involve discussion on -project or -devel. Let's take choice 3 as an example. * Devuan reports a bug in dpkg independent of init systems that they can reproduce on Debian. We're happy to take their bug report. * They don't get a response in the time frame they are hoping for. They write to the DPL. (the DPL does sometimes get messages from people outside the community hoping for help in getting things to move faster). The DPL looks at the issue and decides how much of their time they want to invest. Perhaps the DPL writes a polite note explaining that Debian developers are all volunteers. Perhaps the DPL prods the dpkg maintainer and asks if there's any way it can move faster. Perhaps the DPL gives a suggestion on how Devuan can make the bug report more useful (better test case, comments about a patch). Perhaps the DPL solicits someone in the Debian community to do the above. * Devuan wonders whether it still makes sense for them to submit patches to packages including init scripts under choice 3. We have a discussion on -devel and if there is a consensus let them know what it is. * A derivative writes to us asking if we'd consider a patch to make things easier in some way when not running systemd. We review the patch just as we would (and just as [in]efficiently) other patch submissions we get. Under choice 2: One of the reasons that I started looking into this was requests I got from people inside Devuan about challenges with elogind in Debian. It turns out I got the same request with people involved in maintaining elogind inside Debian too, and I focused on that side of the request more than the Devuan request. I didn't understand the project consensus on how much we value elogind enough to understand what I should do. Some of the feedback I got from within Debian was that sysvinit was dead and people were not reviewing patches/engaging with elogind issues because they hoped it would go away. If the project supports choice 3, that's a fine response. If we support choice 1 or choice 2, that's not a great response from someone who is in a gatekeeper role. In my mind commitment to work with downstreams is far more about letting them know how they can interact with Debian and what they can expect. It is not a promise to do any particular thing, more a commitment to keep communication lines open. Choice 1 Policy Language ======================== >>>>> "Ansgar" == Ansgar <ans...@43-1.org> writes: >> Choice 1: Affirm Init Diversity >> >> Being able to run Debian systems with init systems other than >> systemd continues to be something that the project values. With >> one exception, the Debian Project affirms the current policy on >> init scripts and starting daemons (policy 9.3.2, 9.11). Ansgar> I would not recommend referring to the "current policy" as Ansgar> it is unclear Ansgar> what that is. I understand your concern. I'd be delighted to work with proponents of init system diversity to reword choice 1 without referring to current policy language if that's something they want to do. And certainly anyone can propose an amendment to that effect. My rationale for choice 1 as it stands today is that I've gotten significant feedback from some people that they want a status quo option in terms of the current policy. I did have enough discussions with Russ that I think the summary in choice 1 of what current policy means is fairly accurate. If we get the right people engaged in a discussion of rewording choice 1, I think it would be great. >>>>> "Holger" == Holger Levsen <hol...@layer-acht.org> writes: Constitutional Basis ==================== Holger> I fail to see why Constitution section 4.1 (5) is referred Holger> here. I'd better understand section 4.1 (4) and would Holger> probably would prefer to leave out this half sentence Holger> completly. The secretary has expressed a preference for making it clear what constitutional power is used when proposing a resolution. That was in a TC context, but I think applies equally here. I prefer 4.1(5) to 4.1 (4) for a couple of reasons. TFor those who don't have the constitution memorized we're debating whether to make a statement of the day (4.1 (5)) or to make a decision under TC power (4.1 (4)). A statement of the day is less forceful; it doesn't have any formal power. It lets us understand consensus, but allows maintainers and policy editors to interpret what we say. If it turns out we missed some key issue in our discussion, they can even come back to debian-devel and raise the issue. If we used TC power, we'd need to decide which TC power to use. Presumably you'd be thinking of 6.1.1 (setting technical policy). I guess you could be talking about 6.1 (5: offering advice), but that's so close to a statement of the day that it doesn't make sense to me. Setting policy requires us to get a lot more precise and to get the details right in a way that seems hard for a GR. Also, using power under 4.1 (4) requires a 2:1 majority, where as simply making a statement of the day is a simple majority. I think that if we know the views of the project, the rest will fall into place in policy and in other areas. So I prefer to use the smallest hammer that will accomplish that goal. Choice 1: RC or Not =================== >>>>> "Wouter" == Wouter Verhelst <wou...@debian.org> writes: >> Policy editors are requested to amend policy; including a service >> unit without an init script is appropriate for a non-maintainer >> upload but should no longer be an RC bug. Wouter> If this choice wins, then why should it not be an RC bug to Wouter> not have an init script? That doesn't seem to make sense. In current policy, it's a normal bug to not include an automated way of starting a daemon at all. So, no init script, no systemd unit is a normal bug. But if you provide a systemd unit without a init script, that is an RC bug. While I did not get review of the final text from my init diversity reviewer, I did discuss this particular point with a number of people who favor init diversity. Overwhelmingly they were asking for the ability to be able to work on init diversity. They weren't talking about blocking other people's work or about stopping people from using systemd. They just wanted their patches reviewed in a timely manner, wanted to be able to decide what was good enough for sysvinit users, and wanted patches that met that bar (and didn't introduce other problems) to be accepted. The current policy is very much perceived as the init diversity crowd trying to hold the RC hammer over others. Multiple people were either surprised that policy reads as it does today, or that the policy editors couldn't get consensus to make this change on their own. I was prepared to have two versions of choice 1: one with no init script RC, and the current version. But at least in the people I talked to, I wasn't seeing a strong enough desire for the init script RC option. Holger> On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: >> ---------------------------------------- version 2330c05afa4 >> Choice 3: systemd without Diversity as a Priority Holger> [...] Choice 3 Title ============== Holger> a.) 'systemd without diversity as a priority' sounds like Holger> systemd is against diversity. I think this is borderline Holger> insulting. So I expect this will attract someone proposing Holger> another option called 'Embrace the future (*) and a modern Holger> init system' or such. *) or 'Embrace new technologies...' The systemd maintainers I ran the text by didn't complain about the title. Please speak up if you find the current title insulting toward systemd. I'm taking holger's current wording as a potential concern, not as something that he specifically finds insulting himself. Systemd Features Beyond Init ============================ Holger> On top of all of this, systemd provides much more features Holger> than unit files as the thread on -devel showed. There is no Holger> word about these technologies in this GR proposal. I think Holger> that's a flaw in this proposal. This proposal actually does speak to that issue. Obviously, the policy process may adopt limits on systemd technologies we use, and nothing in this proposal stops people from working to form a consensus on such a limit. But absent limits in policy, maintainers can generally use any systemd feature they like that the systemd maintainers enable in our builds. The question is wether maintainers need to provide non-systemd alternatives when they use such a feature. This proposal does speak to that choice. Choice 2 and 3 say that individual maintainers may include alternatives for individual systemd features if they choose. That may is intended to be my permissive: my reading of choice 2 and 3 is that it is not a bug to use a systemd feature without an alternative.