Proposal: General Resolution on Init Systems and systemd Facilities

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposal: General Resolution on Init Systems and systemd Facilities

Sam Hartman-5


I'd like to propose the following resolution.

Seconds are not required, but it would be valuable to get confirmation
that the three choices contained in this proposal are worth having on
the ballot.
So, rather than seconding the proposal it would be useful if people
would ack choices here they'd like to see on the ballot.

Amendments will require seconds as usual.

Timeline: I think that two weeks for discussion of this GR seems about
right based on what's happened in the last week.  The constitution
allows the DPL to change the discussion period by up to a week.  The
discussion period is normally reset by the proposer accepting any
amendment or making a modification to the proposal.  If an amendment is
accepted, I am likely to use that power such that the discussion period
is the longer of two weeks from when the secretary sends mail to
debian-devel-announce, or seven days past the time of the last amendment
being accepted.  In other words, if I accept an amendment in the next
week, I'm likely to keep the total discussion period at two weeks.

That said, if it looks like we need more time, I can always lengthen the
discussion period.
I do not see any circumstances under which I'd like to shorten the
voting period for this proposal.

----------------------------------------
version: d429a990a09
Changes since initial draft:


* Clarify that packages may need to handle early boot in an init-system-specific manner in choice 1

* Clean up wording around the requested policy change in choice 1

* Adopt Russ's option B for choice 1 at least until we get clear
  direction from that community.

* Adopt Russ's option C for choice 2.

* Adopt something similar to Russ's option D for choice 3

* Add my name to choices to make life easier on the secretary as others get sufficient seconds.

* Revise the title of choice 3 to avoid concerns that it is insulting
  to proponents of systemd.



----------------------------------------

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.  The GR process remains
available if the project needs a decision and cannot come to a
consensus.

Choice hartmans1: 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).  Roughly, packages
should include init scripts to start services that are included.
Policy notes that early boot services like those started from
/etc/rcS.d may be tied closely to the init system in use and thus may need to be handled differently for each init system.  Init
scripts are the lowest common denominator across all init systems.
Packages may include support for init systems like systemd service
units in addition to init scripts.  Current policy makes it an RC bug
to include a service unit without an init script.

Policy editors are requested to amend policy; a package having a
service unit but without an init script is no longer an RC bug, but
including an init script is appropriate for a non-maintainer upload.
Policy editors are requested to consider whether there are cases where
removing an init script that used to be provided should be RC because
it would break a system on upgrade.

Once the community of users of an alternate init system have said that
a solution is sufficiently functional for them, others should not
generally second guess this determination.

systemd unit files included in the package may use any systemd feature
or service at the package maintainer's discretion, provided that this
is consistent with other Policy requirements and the normal
expectation that packages shouldn't depend on experimental or
unsupported (in Debian) features of other packages.

Init scripts must use only facilities common to all supported init
systems in Debian and therefore may not use services that depend on
systemd.

Similarly, packages may freely use other systemd facilities such as
timer units, subject to the above constraints, but not also supporting
non-systemd systems is a (non-RC) bug and non-maintainer uploads to add
that support are appropriate.

systemd facilities may be used at the discretion of package
maintainers, but 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.

Choice hartmans2: systemd but we Support Exploring Alternatives

The Debian project recognizes that systemd service units are the
preferred configuration for describing how to start a daemon/service.
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.

Packages should include service units or init scripts to start daemons
and services.  Packages may use any systemd facility at the
package maintainer's discretion, provided that this is consistent with
other Policy requirements and the normal expectation that packages
shouldn't depend on experimental or unsupported (in Debian) features
of other packages.  Packages may include support for alternate init
systems besides systemd and may include alternatives for any
systemd-specific interfaces they use.  Maintainers use their normal
procedures for deciding which patches to include.


Debian is committed to working with derivatives that make different
choices about init systems.  As with all our interactions with
downstreams, the relevant maintainers will work with the downstreams to
figure out which changes it makes sense to fold into Debian and which
changes remain purely in the derivative.


Choice hartmans3: Focus on systemd for Init System and Other Facilities

The Debian project recognizes that systemd service units are the
preferred configuration for describing how to start a daemon/service.
Packages should include service units or init scripts to start daemons
and services.  Unless the project or relevant parties have agreed
otherwise, systemd facilities, where they exist and are stable and
supported by the systemd maintainers, should be preferred over
Debian-specific ways of solving the same problem unless the Debian
approach has clear and obvious advantages.


Providing support for multiple init systems or for alternatives to
other interfaces provided by systemd is not a project priority at this
time.

Debian is committed to working with derivatives that make different
choices about init systems.  As with all our interactions with
downstreams, the relevant maintainers will work with the downstreams to
figure out which changes it makes sense to fold into Debian and which
changes remain purely in the derivative.

Packages may include support for alternate init systems besides
systemd.  Maintainers use their normal procedures for deciding which
patches to include.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Luk Claes
The three options of your proposal are worthwhile to have on the ballot.

Cheers

Luk

Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
In reply to this post by Sam Hartman-5
Sam Hartman <[hidden email]> writes:

> I'd like to propose the following resolution.

> Seconds are not required, but it would be valuable to get confirmation
> that the three choices contained in this proposal are worth having on
> the ballot.  So, rather than seconding the proposal it would be useful
> if people would ack choices here they'd like to see on the ballot.

I will vote all three of these options above further discussion and am
comfortable with all three options from a Policy guidance standpoint.

Thank you!

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

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

Brian Gupta-2


On Thu, Nov 14, 2019 at 7:09 PM Russ Allbery <[hidden email]> wrote:
Sam Hartman <[hidden email]> writes:

> I'd like to propose the following resolution.

> Seconds are not required, but it would be valuable to get confirmation
> that the three choices contained in this proposal are worth having on
> the ballot.  So, rather than seconding the proposal it would be useful
> if people would ack choices here they'd like to see on the ballot.

I will vote all three of these options above further discussion and am
comfortable with all three options from a Policy guidance standpoint.

Thank you!

I would like to see an additional option to leave current policy unchanged. Obviously if I am alone in wanting this option, please disregardt.

-Brian
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Brian Gupta <[hidden email]> writes:

> I would like to see an additional option to leave current policy
> unchanged.  Obviously if I am alone in wanting this option, please
> disregardt.

What does that mean to you?  I ask because Policy is a little incoherent
and a lot incomplete.

Are you specifically looking for an option that says that packages that
support systemd are required to support sysvinit and that it's an RC bug
if they don't?

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

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

Matthias Klumpp-2
In reply to this post by Sam Hartman-5
Am Do., 14. Nov. 2019 um 21:24 Uhr schrieb Sam Hartman <[hidden email]>:
>
> I'd like to propose the following resolution.
>
> Seconds are not required, but it would be valuable to get confirmation
> that the three choices contained in this proposal are worth having on
> the ballot.
> So, rather than seconding the proposal it would be useful if people
> would ack choices here they'd like to see on the ballot.
> [...]

I think all three options put forward are very well worded and I
would, like Russ, prefer any one of them over further discussion.

Thank you for preparing this!

--
I welcome VSRE emails. See http://vsre.info/

Reply | Threaded
Open this post in threaded view
|

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

Brian Gupta-2
In reply to this post by Russ Allbery-2


On Thu, Nov 14, 2019 at 9:13 PM Russ Allbery <[hidden email]> wrote:
Brian Gupta <[hidden email]> writes:

> I would like to see an additional option to leave current policy
> unchanged.  Obviously if I am alone in wanting this option, please
> disregardt.

What does that mean to you?  I ask because Policy is a little incoherent
and a lot incomplete.

Are you specifically looking for an option that says that packages that
support systemd are required to support sysvinit and that it's an RC bug
if they don't?

Yes. That was my understanding of the tortured consensus from a few years ago. Paraphrasing.. "Yes, we'll pick a sane default, but don't worry, We won't be removing support for other systems."

-Brian
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Brian Gupta <[hidden email]> writes:
> On Thu, Nov 14, 2019 at 9:13 PM Russ Allbery <[hidden email]> wrote:

>> Are you specifically looking for an option that says that packages that
>> support systemd are required to support sysvinit and that it's an RC
>> bug if they don't?

> Yes. That was my understanding of the tortured consensus from a few
> years ago. Paraphrasing.. "Yes, we'll pick a sane default, but don't
> worry, We won't be removing support for other systems."

Ah, okay.  In that case you should probably second either Dmitry or Ian's
proposal (Dmitry's says that explicitly; Ian's strikes a slightly
different compromise that is worth considering).

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

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

Scott Kitterman-5
In reply to this post by Sam Hartman-5


On November 14, 2019 8:08:28 PM UTC, Sam Hartman <[hidden email]> wrote:

>
>
>I'd like to propose the following resolution.
>
>Seconds are not required, but it would be valuable to get confirmation
>that the three choices contained in this proposal are worth having on
>the ballot.
>So, rather than seconding the proposal it would be useful if people
>would ack choices here they'd like to see on the ballot.
>
>Amendments will require seconds as usual.
>
>Timeline: I think that two weeks for discussion of this GR seems about
>right based on what's happened in the last week.  The constitution
>allows the DPL to change the discussion period by up to a week.  The
>discussion period is normally reset by the proposer accepting any
>amendment or making a modification to the proposal.  If an amendment is
>accepted, I am likely to use that power such that the discussion period
>is the longer of two weeks from when the secretary sends mail to
>debian-devel-announce, or seven days past the time of the last
>amendment
>being accepted.  In other words, if I accept an amendment in the next
>week, I'm likely to keep the total discussion period at two weeks.
>
>That said, if it looks like we need more time, I can always lengthen
>the
>discussion period.
>I do not see any circumstances under which I'd like to shorten the
>voting period for this proposal.
>
>----------------------------------------
>version: d429a990a09
>Changes since initial draft:
>
>
>* Clarify that packages may need to handle early boot in an
>init-system-specific manner in choice 1
>
>* Clean up wording around the requested policy change in choice 1
>
>* Adopt Russ's option B for choice 1 at least until we get clear
>  direction from that community.
>
>* Adopt Russ's option C for choice 2.
>
>* Adopt something similar to Russ's option D for choice 3
>
>* Add my name to choices to make life easier on the secretary as others
>get sufficient seconds.
>
>* Revise the title of choice 3 to avoid concerns that it is insulting
>  to proponents of systemd.
>
>
>
>----------------------------------------
>
>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.  The GR process remains
>available if the project needs a decision and cannot come to a
>consensus.
>
>Choice hartmans1: 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).  Roughly, packages
>should include init scripts to start services that are included.
>Policy notes that early boot services like those started from
>/etc/rcS.d may be tied closely to the init system in use and thus may
>need to be handled differently for each init system.  Init
>scripts are the lowest common denominator across all init systems.
>Packages may include support for init systems like systemd service
>units in addition to init scripts.  Current policy makes it an RC bug
>to include a service unit without an init script.
>
>Policy editors are requested to amend policy; a package having a
>service unit but without an init script is no longer an RC bug, but
>including an init script is appropriate for a non-maintainer upload.
>Policy editors are requested to consider whether there are cases where
>removing an init script that used to be provided should be RC because
>it would break a system on upgrade.
>
>Once the community of users of an alternate init system have said that
>a solution is sufficiently functional for them, others should not
>generally second guess this determination.
>
>systemd unit files included in the package may use any systemd feature
>or service at the package maintainer's discretion, provided that this
>is consistent with other Policy requirements and the normal
>expectation that packages shouldn't depend on experimental or
>unsupported (in Debian) features of other packages.
>
>Init scripts must use only facilities common to all supported init
>systems in Debian and therefore may not use services that depend on
>systemd.
>
>Similarly, packages may freely use other systemd facilities such as
>timer units, subject to the above constraints, but not also supporting
>non-systemd systems is a (non-RC) bug and non-maintainer uploads to add
>that support are appropriate.
>
>systemd facilities may be used at the discretion of package
>maintainers, but 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.

This option makes multiple references to RC and non-RC bugs based on actions of the policy editors.

It's my understanding that determining if a bug is RC or not is a Release Team function, not the policy editors.

Would it be better to use something like 'severe policy violation' (and it's opposite) than Release Critical?

Scott K

Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Scott Kitterman <[hidden email]> writes:

> This option makes multiple references to RC and non-RC bugs based on
> actions of the policy editors.

> It's my understanding that determining if a bug is RC or not is a
> Release Team function, not the policy editors.

> Would it be better to use something like 'severe policy violation' (and
> it's opposite) than Release Critical?

No objections here but I think it's a minor issue.  These are generally
kept in sync except that the release team is free to declare violations of
a Policy must to not be release-critical in the service of getting a
release out and scoping the amount of work we're committing to do.  (The
contrary should *not* be true and only is due to lack of resources;
anything that the release team considers release-critical should be a must
in Policy, and bug reports are welcome in any place this is not in sync.)

If a Policy must is declared not release critical for release after
release, I'd like to synchronize and downgrade it to a should.  The goal
is for both policies to say the same thing except for temporary
exceptions.

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

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

Scott Kitterman-5


On November 15, 2019 3:26:31 AM UTC, Russ Allbery <[hidden email]> wrote:

>Scott Kitterman <[hidden email]> writes:
>
>> This option makes multiple references to RC and non-RC bugs based on
>> actions of the policy editors.
>
>> It's my understanding that determining if a bug is RC or not is a
>> Release Team function, not the policy editors.
>
>> Would it be better to use something like 'severe policy violation'
>(and
>> it's opposite) than Release Critical?
>
>No objections here but I think it's a minor issue.  These are generally
>kept in sync except that the release team is free to declare violations
>of
>a Policy must to not be release-critical in the service of getting a
>release out and scoping the amount of work we're committing to do.
>(The
>contrary should *not* be true and only is due to lack of resources;
>anything that the release team considers release-critical should be a
>must
>in Policy, and bug reports are welcome in any place this is not in
>sync.)
>
>If a Policy must is declared not release critical for release after
>release, I'd like to synchronize and downgrade it to a should.  The
>goal
>is for both policies to say the same thing except for temporary
>exceptions.

Okay.  My thought is that it's cleaner to state this GR is about the project position on policy and not about the Release Team's execution of its delegated authority if we stay away from the RC terminology.

We may all know what we mean now, but GRs seem to get referenced for a very long time.  I think it's worth it for 15 years from now Debian to be as clean and clear as we can now.

Scott K

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
In reply to this post by Sam Hartman-5
Sam Hartman writes ("Proposal: General Resolution on Init Systems and systemd Facilities"):
> Timeline:

Please can we have more time.

Ian.

Reply | Threaded
Open this post in threaded view
|

Time Line

Sam Hartman-3
>>>>> "Ian" == Ian Jackson <[hidden email]> 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 productive discussion refiding the words of one of
the viable proposals, sure, I'd  make sure we had more time.

But I think two weeks is enough time to judge basic support and
viability of a proposal.  That is, I think within two weeks proposal
authors ought to be able to find seconds or find people who would second
if a particular likely-to-be-resolved issue is resolved.

You are right that this decision is not hugely timely.
However we've seen time and time again that the project views these long
discussions as costly.
I saw someone on IRC just yesterday saying they had recently spent 16
hours on init system GR stuff.
I was shocked.
I mean, yeah I've spent well over that time on this issue, but I've made
that my job.
If other develpers, particularly developers who are not primary
contributors to the discussion are already feeling burned out and are
spending significant time because they have to keep up, that is a real
significant cost to the project.

So, I want to be efficient about this process.  I don't think it is
worth delaying for proposals that have not demonstrated that they will
be able to close issues and get necessary support to be on a ballot.

However, yes, if there is a subcommunity that is coming towards a
consensus to refine or merge a proposal, delaying to accomplish that
seems valuable.

If we're circling around not actually making progress, I'm less
supportive of a delay.

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
In reply to this post by Sam Hartman-5
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, timer units, sysusers.d, etc.

There are a number of these, and more of them are going to come along.
We need a better framework for handling these cases.  If we do nothing
else then both of your options 1 and 2 lead to a mess.

For example, suppose upstream ship a timer unit.  A Debian contributor
wants to supply a patch to make the package use cron.  You might very
well want to use cron even with systemd; some people prefer cron's
featureset.  How is this supposed to be resolved in practice ?  The
non-systemd-using contributor of the cron job might which to simply
add a dependency on cron and disable the timer unit by default.  Or
are the timer units supposed to be patched to be disabled when cron is
installed ?

It seems to me that these kind of technical details will need to be
resolved via the policy process.  These discussions are specific to
each facility.  In some cases we will want to simply provide an
implementation of (perhaps a subset of) the systemd functionality.

I think these decisions ought to be taken on a faciliy-by-facility
basis.  That's why my proposal sets out a set of criteria for judging
whether a facility's interface ought to be adopted by Debian.  If the
facility is adopted, the non-systemd folks (like me) will have to
implement it; if not, it should not be used and if necessary upstream
arrangements should be patched to use a more general facility instead.


> Choice hartmans3: Focus on systemd for Init System and Other Facilities

If this option wins I will significantly reduce my involvement in
Debian.  I think there are probably other contributors for whom this
is the case.  I imagine that there are contributors for whom option 1
(or Dmitry's option) is similarly awful.


One of the most damaging things the systemd wars have done is to turn
bugs into fights.

Fights are awful.  Bugs are fine.  We have lots of bugs and we enjoy
fixing them.  My proposal is trying to turn the fights back into bugs.


Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-3
>>>>> "Ian" == Ian Jackson <[hidden email]> 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 is this supposed to
    Ian> be resolved in practice ?  The non-systemd-using contributor of
    Ian> the cron job might which to simply add a dependency on cron and
    Ian> disable the timer unit by default.  Or are the timer units
    Ian> supposed to be patched to be disabled when cron is installed ?

    Ian> It seems to me that these kind of technical details will need
    Ian> to be resolved via the policy process.  These discussions are
    Ian> specific to each facility.

We're agreed so far.

    Ian> In some cases we will want to
    Ian> simply provide an implementation of (perhaps a subset of) the
    Ian> systemd functionality.

    Ian> I think these decisions ought to be taken on a
    Ian> faciliy-by-facility basis.  That's why my proposal sets out a
    Ian> set of criteria for judging whether a facility's interface
    Ian> ought to be adopted by Debian.

Right.
And the disagreement is whether the answer is a presumed yes you can use
the facility or you need to go through the process ahead of time.
I believe that my options accurately reflect the discussion I was trying
to capture.

The up-side of that is that it makes it easy to use new facilities.
The down sides are the ones you've pointed out.

As people find bugs they don't know how to solve, policy will have to
catch up.

But we're used to that.
I think that you could find a few people who want to support both
systemd timers and cron jobs together.
And once you found a good way to do that, you could get it into policy.

Your proposal blocks people from using the new facility until that
discussion happens.

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.

In both cases we hopefully turn fights into bugs.

Reply | Threaded
Open this post in threaded view
|

Re: Time Line

Simon Richter
In reply to this post by Sam Hartman-3
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 already feeling burned out and are
> spending significant time because they have to keep up, that is a real
> significant cost to the project.

I still think it is time spent well, because the alternative is lots of
small chunks of people's time lost in a less visible way -- from patches
being prepared but not integrated to local workarounds built by sysadmins.

The ideal outcome of this process is that we reach a consensus that can be
extrapolated even to future questions. A less ideal outcome is that we
reach a decision instead of a consensus -- but even that would be
worthwhile.

   Simon

Reply | Threaded
Open this post in threaded view
|

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

Ansgar Burchardt-5
In reply to this post by Sam Hartman-3
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 facility.  We've seen people not caring about problems with
consolekit/systemd-shim for far longer times; so giving them such
blocks seems not a good idea to me (more so if the proposal is titled
"[...] without blocking progress").

That doesn't seem much different from the "loose init coupling" idea
that was proposed for two GRs earlier, except there is a possible way
for progress after a long discussion period and additional 6-12 months
of waiting.

Historically, we've also started to use new facilities without having
a-priory decisions about them: most things added to Policy have slowly
been gaining usage for some time before.  I don't think we should
change that approach.

Ansgar


Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
In reply to this post by Sam Hartman-3
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 because it makes things
continuing to work on non-systemd systems dependent on policy
consensus, and therefore on the agreement of systemd advocates.

All my proposal does is temporarily delay the adoption of useful new
features, to give a reasonable time for consideration (with a clear
escalation path) and implementation.  No systemd advocates will find
their useful work indefinitely blocked.

> And the disagreement is whether the answer is a presumed yes you can use
> the facility or you need to go through the process ahead of time.
> I believe that my options accurately reflect the discussion I was trying
> to capture.
>
> The up-side of that is that it makes it easy to use new facilities.
> The down sides are the ones you've pointed out.

The problem with even your option B is that there is no effective
route for non-systemd systems to "catch up" as you put it.

> I think that you could find a few people who want to support both
> systemd timers and cron jobs together.
> And once you found a good way to do that, you could get it into policy.

Getting it into policy is going to be very difficult.  People who only
want to do systemd will see that they can get what they want ("just
use all the systemd features and don't have to worry about anything
else") by blocking policy change.

Even when a shared approach is agreed in policy, there will be nothing
stopping maintainers from, for example, using new systemd subfeatures
of questionable value, and breaking things again.

Sometimes the interface agreed in policy will have to be not "just the
systemd thing" (eg with timer units) and then maintainers will be able
to block support by just stalling on patches.  For example, patches to
do some kind of conditional cron vs timer unit thing will probably be
thought ugly and not accepted.

So I am saying that your option B is setting us up for more years of
fighting.  I don't want more years of fighting.  I want us to do
programming instead.

> Your proposal blocks people from using the new facility until that
> discussion happens.

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
shouldn't be) other fields of our distro where adoption of new
features which require new work by a significant number of people, can
be done without any kind of discussion.

Russ, Sam has mentioned your name.  Are you happy with the situation
that is being set up with option B ?

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Ian Jackson <[hidden email]> 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
> shouldn't be) other fields of our distro where adoption of new features
> which require new work by a significant number of people, can be done
> without any kind of discussion.

> Russ, Sam has mentioned your name.  Are you happy with the situation
> that is being set up with option B ?

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 Policy.  I think all these options can be made to work, but your
proposal, as well as options A and D from my original message, are much
cleaner and more straightforward and I think would lead to less arguing
and fewer demands on the Policy process.

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
option for other communities to provide their own implementation of those
interfaces and to delay adoption of the interface for a reasonable length
of time.  The second is a lot more work than the first, to be clear, but I
think it's work we can do.

That said, I think all of these options are better than the current
situation of no guidance, so I'll vote all of these options above further
discussion.

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

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

Sean Whitton
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 Policy.  I think all these options can be made to work, but your
> proposal, as well as options A and D from my original message, are much
> cleaner and more straightforward and I think would lead to less arguing
> and fewer demands on the Policy process.

I agree with this assessment that Ian's proposal would allow the Policy
process to get more done, in the sense of both building and documenting
project consensus.

I appreciate that, from the point of view of a proponent of new systemd
features, this getting more done in Policy will seem to be in tension
with getting more done in the archive.

As a counterpoint to that, I think that the Policy process is an
important part of how we get things done in the archive in the longer
term, and Ian's proposal speaks to that.

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.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
123