Re: Proposal: General Resolution on Init Systems and systemd Facilities

Simon Richter writes: > GNOME and systemd coordinate among themselves mostly, adding features as > required for their use cases. As long as no one outside these particular > ecosystems uses these features, we can just step aside and wait for > wider adoption. > The majority of packages we have i

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Hi, On Fri, Nov 15, 2019 at 10:03:35AM -0800, Russ Allbery wrote: > My personal preference is for the project to either decide that we're > going to use systemd facilities by default and sysvinit is going to break, > or to decide that we're going to require standardized interfaces with the > opti

Re: [draft] Draft text on Init Systems GR

Russ Allbery writes: > Ansgar writes: >> Note that this would also block updating upstream packages to new >> releases, possibly delaying development for a long time. I don't think >> we need much slower development cycles. > > I'm not sure why you think this is the case. Could you explain more

Re: Proposal: General Resolution on Init Systems and systemd Facilities

On Fri, Nov 15, 2019 at 01:22:26PM -0700, Sean Whitton wrote: > If we found that the six month delay was repeatedly expiring with no > serious attempts at non-systemd implementations of the new features, we > could repeal this GR. I'm pondering an amendment to copy this option but without the 6 mo

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Hello, On Fri 15 Nov 2019 at 10:03AM -08, Russ Allbery wrote: > I think I would rather have the clear path forward your proposal lays out, > with a 6-12 month delay, than to have my options B or C that set up Policy > discussions for each new feature while maintainers move forward in advance > of

Re: [draft] Draft text on Init Systems GR

Ansgar writes: > It doesn't have to have the same complexity as logind or udev. Keep in > mind that Policy doesn't even document init scripts properly: in > particular LSB comment headers and such are also missing. We weren't > able to document that in Policy for a long time and other Polic

Re: Draft text on Init Systems GR

Ian Jackson writes: > Russ Allbery writes ("Re: Draft text on Init Systems GR"): >> As Policy editor, I would interpret "designed to work exclusively with >> systemd" as including any software that, upstream, had a hard >> dependency on a systemd feature. That includes obvious things like >> log

Re: [draft] Draft text on Init Systems GR

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"): > Ian Jackson writes: > > Here is my proposal. It is unfortunately quite long. The reason is > > that I am trying to address the dysfuncdtional patterns I have seen over > > the past few years, and give specific remedies. > > Af

Re: Draft text on Init Systems GR

Russ Allbery writes ("Re: Draft text on Init Systems GR"): > As Policy editor, I would interpret "designed to work exclusively with > systemd" as including any software that, upstream, had a hard dependency > on a systemd feature. That includes obvious things like logind, but also > daemons meant

Re: [draft] Draft text on Init Systems GR

Russ Allbery writes: > Ansgar writes: >> On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote: >>> As with Dmitry's proposal, I'm not seconding this because it's not my >>> own first choice, but I would vote this above further discussion and >>> I'm satisfied that it's clear about the Policy impli

Re: [draft] Draft text on Init Systems GR

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"): > I was assuming that logind was out of scope (as was udev) because both > have already been adopted by Debian, so this isn't the same situation that > Ian's proposal is describing. The remaining facilities that I was > thinking ab

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Ian Jackson writes: > My proposal provides a clear escalation path, and clear guidance to the > TC. No useful new facilities will be blocked forever. > It is true that adoption of new facilities does in my proposal depend on > some discussion. But indeed that is reasonable. There aren't (or >

Re: Draft text on Init Systems GR

Thibaut Paumard writes: > I think this is very ambiguous and my immediate interpretation is > probably not what the original proposer means. The two extreme > interpretations I see for "designed to work exclusively with systemd" > are: > - my guess for the OP meaning: some piece of software th

Re: Draft text on Init Systems GR

Andrey Rahmatullin writes: > On Fri, Nov 15, 2019 at 01:10:58AM -0500, Brian Gupta wrote: >> Do you think it's ok in any case to remove init scripts. Let's say an >> upstream stops maintaining init scripts, > In my experience init scripts can only be written for Debian, not > "maintained upstrea

Re: [draft] Draft text on Init Systems GR

Ian Jackson writes: > Here is my proposal. It is unfortunately quite long. The reason is > that I am trying to address the dysfuncdtional patterns I have seen over > the past few years, and give specific remedies. After sleeping on this, I am going to second this proposal. I think it's superi

Re: [draft] Draft text on Init Systems GR

Ansgar writes: > On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote: >> As with Dmitry's proposal, I'm not seconding this because it's not my >> own first choice, but I would vote this above further discussion and >> I'm satisfied that it's clear about the Policy implications. > Do you think

Re: [draft] Draft text on Init Systems GR

Hi Russ, On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote: > As with Dmitry's proposal, I'm not seconding this because it's not my own > first choice, but I would vote this above further discussion and I'm > satisfied that it's clear about the Policy implications. Do you think it is realisti

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Sam Hartman writes ("Re: Proposal: General Resolution on Init Systems and systemd Facilities"): > Under Russ's option B and C, which I capture in my proposal, non-systemd > users get degraded behavior until we agree on an approach and > standardize it. The reason this is unacceptable to me is bec

Re: Proposal: General Resolution on Init Systems and systemd Facilities

On Fri, 2019-11-15 at 07:39 -0500, Sam Hartman wrote: > Your proposal blocks people from using the new facility until that > discussion happens. It also allows non-systemd to block progress for 6-12 months even after discussion and at any later time for any enhancement (new feature) of any facilit

Re: Draft text on Init Systems GR

Hi, On Fri, Nov 15, 2019 at 10:29:10AM +0100, Thibaut Paumard wrote: > I think this is very ambiguous and my immediate interpretation is > probably not what the original proposer means. The two extreme > interpretations I see for "designed to work exclusively with systemd" are: > - my guess fo

Re: [draft] Draft text on Init Systems GR

On Fri, 2019-11-15 at 07:11 -0500, Sam Hartman wrote: > Ian> * Declining to accept init scripts, or arguing against the > Ian> inclusion of init scripts, on the grounds that they should > be > Ian> properly tested by the maintainer and the author doesn't > Ian> consider testing the

Re: Proposal: General Resolution on Init Systems and systemd Facilities

> "Ian" == Ian Jackson writes: Ian> For example, suppose upstream ship a timer unit. A Debian Ian> contributor wants to supply a patch to make the package use Ian> cron. You might very well want to use cron even with systemd; Ian> some people prefer cron's featureset. How

Re: Time Line

Hi Sam, On Fri, Nov 15, 2019 at 06:58:33AM -0500, Sam Hartman wrote: > I saw someone on IRC just yesterday saying they had recently spent 16 > hours on init system GR stuff. That was me. > If other develpers, particularly developers who are not primary > contributors to the discussion are alrea

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Sam Hartman writes ("Proposal: General Resolution on Init Systems and systemd Facilities"): > Choice hartmans1: Affirm Init Diversity I have read through these options and I find them unsatisfactory in their treatment of what I'm calling `non-init-related declarative systemd facilities'. Eg, tim

Re: [draft] Draft text on Init Systems GR

> "Ian" == Ian Jackson writes: Ian> The patterns I am trying to address with this are things like: Ian> * Vague RC bug reports against pieces of the non-systemd Ian> ecosystem, which do not actually describe a particular bug, or Ian> an approach acceptable to the submitter,

Time Line

> "Ian" == Ian Jackson writes: Ian> Sam Hartman writes ("Proposal: General Resolution on Init Ian> Systems and systemd Facilities"): >> Timeline: Ian> Please can we have more time. If you're worried about still finalizing wording or what happens if we're actively in a produc

Re: Draft text on Init Systems GR

Brian Gupta writes ("Re: Draft text on Init Systems GR"): > On Thu, Nov 14, 2019 at 7:51 PM Dmitry Bogatov wrote: > > Dmitry Bogatov writes ("Draft text on Init Systems GR"): > > > Choice 1: Affirm Init Diversity ... > Do you think it's ok in any case to remove init scripts. Let's say

Re: [draft] Draft text on Init Systems GR

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"): > I wish that a GR had the moral suasion that would get everyone to be > excellent to each other, but I'm somewhat dubious. I'm not a huge fan of > trying to tackle that in the same GR as the technical questions, but I > respect wh

Re: [draft] Draft text on Init Systems GR

Sam Hartman writes ("Re: [draft] Draft text on Init Systems GR"): > [Ian's proposal] > >It is also for maintainers of > > non-default init systems, and the surrounding community, to decide > > what level of compromised functionality is acceptable to users of > > non-default init syste

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Sam Hartman writes ("Proposal: General Resolution on Init Systems and systemd Facilities"): > Timeline: Please can we have more time. Ian.

Re: [draft] Draft text on Init Systems GR

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"): > Wouter Verhelst writes: > > The problem with this is that it, essentially, promotes drive-by > > patching: someone would like to use a program, but it doesn't come with > > support for their init system. > > > > So they write tha

Re: [draft] Draft text on Init Systems GR

On Thu, Nov 14, 2019 at 06:32:32PM -0800, Russ Allbery wrote: > Wouter Verhelst writes: > > I think a better solution is to accept that some maintainers simply > > won't have the time or inclination to maintain support for non-default > > init systems, and that such init scripts (or whatever) shou

Re: Draft text on Init Systems GR

Hi, Le 15/11/2019 à 07:10, Brian Gupta a écrit : > > > On Thu, Nov 14, 2019 at 7:51 PM Dmitry Bogatov > wrote: > > > [2019-11-14 17:15] Ian Jackson > > > Dmitry Bogatov writes ("Draft text on Init Systems GR"): >