Proposal: General Resolution on Init Systems and systemd Facilities

[Sam Hartman]

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.

[Luk Claes]

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

Cheers

Luk

[Russ Allbery]

Post by Sam Hartman
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!

[Brian Gupta]

Post by Russ Allbery

Post by Sam Hartman
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

[Russ Allbery]

Post by Brian Gupta
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?

[Brian Gupta]

Post by Russ Allbery

Post by Brian Gupta
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

[Russ Allbery]

Post by Brian Gupta

Post by Russ Allbery
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).

[Matthias Klumpp]

Post by Sam Hartman
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!

[Scott Kitterman]

Post by Sam Hartman
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
* 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

[Russ Allbery]

Post by Scott Kitterman
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.

[Scott Kitterman]

Post by Russ Allbery

Post by Scott Kitterman
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

Post by Scott Kitterman
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

[Ian Jackson]

Please can we have more time.

Ian.

[Sam Hartman]

Ian> Sam Hartman writes ("Proposal: General Resolution on Init
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.

[Simon Richter]

Hi Sam,

Post by Sam Hartman
I saw someone on IRC just yesterday saying they had recently spent 16
hours on init system GR stuff.

That was me.

Post by Sam Hartman
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

[Ian Jackson]

You've started all this, and imposed it to all of us. Some of us
probably didn't want this to happen at all (another systemd discussion
and GR, really?!?), but I still respect your view and your position as a
DPL. However, as we're in it because you decided to go for it, it is my
view that imposing your agenda is questionable. I find it unacceptable
that you're adding pressure, and you seem to be unwilling to give Ian
all the time he needs to prepare a nice text, which I'm sure he will do
in a timely fashion anyways.

One effect of Sam's decision was that I had to quickly make my
proposal formal. Now it is much harder to improve it, if there are
things that could usefully be changed.

Ian.

[Ian Jackson]

For the record: I am aware that Dmitry is in discussions about
possibly improving/changing the wording of his option.

Dmitry's email access is store-and-forward and very slow. The RTT
seems to be substantially more than a day.

I hope we can give him the time to draft the best option to represent
his views and that of what he believes to be his constituency.

Ian.

[Ian Jackson]

Post by Sam Hartman
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.

Post by Sam Hartman
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.

[Sam Hartman]

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.

[Ansgar]

Post by Sam Hartman
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

[Ian Jackson]

Post by Sam Hartman
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.

Post by Sam Hartman
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.

Post by Sam Hartman
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.

Post by Sam Hartman
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.

[Russ Allbery]

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.

[Sean Whitton]

Hello,

Post by Russ Allbery
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.

[Holger Levsen]

Post by Sean Whitton
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 month
delay clause.

[Ian Jackson]

Post by Holger Levsen

Post by Sean Whitton
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 month
delay clause.

In practice, we (in Debian as a whole) generally delay things for much
longer than that, in order to give people a chance to catch up. To me
it seems fair to ask no more of the people who have to reimplement
things for non-systemd, than we ask of other kinds of people who need
to do work to enable beneficial transitions.

Of course we don't have a set timescale for these other things because
they are usually not fraught. Take as an example new GCC versions,
which you typically get /at least/ 6 months from having a clear notice
of a problem and an ability to see that you have fixed it.

If you just delete the bit about the delay, what will you replace it
with ? If you say 0 delay then it amounts to standardising and
recommending in policy a change which actually makes programs buggy as
soon as you apply it.

We could suggest a per-feature negotiation about implementation
timescale but, please, no.

In other words: is it really not worth waiting a very short time in
Debian terms (1/4 of a release cycle) while adopting a feature, in
order to keep a fair few people much happier ?

FTAOD of course what you propose is up to you.

Ian.

[Holger Levsen]

Post by Ian Jackson

Post by Holger Levsen

Post by Sean Whitton
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 month
delay clause.

In practice, we (in Debian as a whole) generally delay things for much
longer than that, in order to give people a chance to catch up.

I'd also say, because delays just happen, even though we have many
people updating software timely in unstable regularily, we also have
regularily delays. I don't think we should add more artifical delays.

Also, your GR text is unclear when those 6 or 12 months start.

And then, let's says systemd and gnome together develop a feature which
is then used by gnome, does that mean that also the gnome maintainers
cannot upload new versions of gnome?

Post by Ian Jackson
If you just delete the bit about the delay, what will you replace it
with ? If you say 0 delay then it amounts to standardising and
recommending in policy a change which actually makes programs buggy as
soon as you apply it.

I'd replace:

[...] The
transition should be smooth for all users. The non-systemd
community should be given at least 6 months, preferably at least 12
months, to develop their implementation. (The same goes for any
future enhancements.)

with

[...] The
transition should be as smooth as possible for all users including
those of alternative init systems.

Post by Ian Jackson
In other words: is it really not worth waiting a very short time in
Debian terms (1/4 of a release cycle)

this delay might well cause further delays to the release cycle, thus
making the release cycle longer (and thus the impact even smaller, one
could say... ;)

Post by Ian Jackson
FTAOD of course what you propose is up to you.

thanks! and, somewhat btw, many thanks for your stated goal of shifting
these, aehm, issues from fights to bugs. Very much appreciated (and quite
successful, I think.)

I'm trying to do the same. I'm really not sure I could rank this proposal
above NOTA with the delay clause, while without I think I could very well.

[Russ Allbery]

I agree with Holger that it's probably better to leave the amount of
time undefined, and see what happens on a case by case basis.

If we're going to expect there to be a transition period, I would prefer
the time be defined, rather than left for case-by-case argument. If folks
would prefer that we have zero delay (as soon as Policy standardizes a
facility currently only supported by systemd, people can start using it
immediately), that's viable from a Policy perspective. But it's hard (and
not particularly fun) work on Policy to decide a reasonable non-zero delay
on a case-by-case basis for every feature.

Ian's text says that we always introduce new feature descriptions and then
pick something between six months and a year before people get to start
using the new thing, and provides an easy out that in the case of
disagreement we can just always pick a year and be done.

This may slow progress, but it removes a point of argument, which is very
appealing.

[Ian Jackson]

Post by Russ Allbery
If we're going to expect there to be a transition period, I would prefer
the time be defined, rather than left for case-by-case argument. If folks
would prefer that we have zero delay (as soon as Policy standardizes a
facility currently only supported by systemd, people can start using it
immediately), that's viable from a Policy perspective.

ISTM that a zero transition period would contradict the requirement,
which Holger and Thomas propose to retain, that "the transition should
be as smooth as possible for all users including those of alternative
init systems".

It would also put non-systemd folks in the position of needing to
block (or delay) policy development simply to give themselves
implementation time. Ie, in practice it would require systemd
sceptics to engage in bad, perhaps even disingenuous, behaviours.

Thomas writes:

I agree with Holger that it's probably better to leave the amount of
time undefined, and see what happens on a case by case basis.

So I guess that's not what he wants.

Post by Russ Allbery
But it's hard (and not particularly fun) work on Policy to decide a
reasonable non-zero delay on a case-by-case basis for every feature.

Exactly.

Post by Russ Allbery
Ian's text says that we always introduce new feature descriptions and then
pick something between six months and a year before people get to start
using the new thing, and provides an easy out that in the case of
disagreement we can just always pick a year and be done.
This may slow progress, but it removes a point of argument, which is very
appealing.

Of course if the (re)implementation(s) of the (new) interface are
complete before the time is up, there would be no reason to continue
to delay, and blessing immediate use would be uncontroversial.

So the delay in my text is a maximum, not a minimum.


And I just want to reset the framing:

There is of course nothing stopping advocates of the new interface,
who are happy with systemd and want to see faster progress, from
helping out with the implementation. Normally that is how we would do
things in Debian: the people who want to change something have to do
that change. Even for things that the project as a whole is extremely
keen on.

Shifting the implementation burden to the community around non-default
init systems is a key part of the compromise embedded into my
proposal. But that does mean that the precise terms of the compromise
need to be in the GR, to avoid continuing debate. The GR needs to
settle as much as it possibly can.

I think this is a good deal for the non-systemd community because
writing code, even to an interface that you didn't design and which
came from systemd, is a much more fun activity than political
fighting. It's also something we are all collectively much better at.

It is a good deal for the systemd community and the project as a whole
because it provides a clear and relatively uncontentious path to
progress.

Obviously for those who would prefer only to worry about systemd, it's
suboptimal. Those people should probably propose their own option (or
vote for Sam's). But I guess Thomas and Holger aren't in that camp
because they are both happy with the rest of my proposal, including
requiring "smooth transition for ... users ... of alternative init
systems".

Ian.

[Ian Jackson]

Post by Ian Jackson
Of course if the (re)implementation(s) of the (new) interface are
complete before the time is up, there would be no reason to continue
to delay, and blessing immediate use would be uncontroversial.
So the delay in my text is a maximum, not a minimum.

I would be open to wording changes which change the emphasis here and
make this point clearer. (While keeping what I see as the actual
effect of the provision basically unchanged, unless someone spots
bugs.)

Thanks,
Ian.

[Holger Levsen]

Post by Russ Allbery

I agree with Holger that it's probably better to leave the amount of
time undefined, and see what happens on a case by case basis.

If we're going to expect there to be a transition period, I would prefer
the time be defined, rather than left for case-by-case argument. If folks
would prefer that we have zero delay (as soon as Policy standardizes a
facility currently only supported by systemd, people can start using it
immediately), that's viable from a Policy perspective. But it's hard (and
not particularly fun) work on Policy to decide a reasonable non-zero delay
on a case-by-case basis for every feature.

aaaaah! Now I see that this is ment differently than it was proposed. Me
blames the length of the third sentence in paragraph #9 in proposal D on
https://www.debian.org/vote/2019/vote_002

What I missed that this delay (of 6/12 month) is a delay for *-policy* about
describing/defining such a feature. I thought it ment to prohibit people
from using such new features.

Of course policy can lag behind 'artificially' (or on purpose), I mean,
fine, as long as new software can be uploaded and make use of such
features. (I really wouldnt want it to become impossible to just upload
the latest gnome release.)

Post by Russ Allbery
Ian's text says that we always introduce new feature descriptions and then
pick something between six months and a year before people get to start
using the new thing, and provides an easy out that in the case of
disagreement we can just always pick a year and be done.

In practice you can and do this already. (By saying, this is too new,
policy describes status quo, etc).

Post by Russ Allbery
This may slow progress, but it removes a point of argument, which is very
appealing.

I wonder why you dont prefer a fixed timeline then. 6 *or* 12 months.

[Russ Allbery]

Post by Holger Levsen
What I missed that this delay (of 6/12 month) is a delay for *-policy*
about describing/defining such a feature. I thought it ment to prohibit
people from using such new features.

It's a delay from the point at which Policy standardizes using systemd
services instead of an existing Debian equivalent to the point where
people should start doing that in the archive.

It doesn't affect upstream introducing new systemd-specific requirements.
It also doesn't affect packagers using systemd-specific features provided
that it doesn't break behavior on other init systems (adding hardening
only on systemd systems, for instance).

Post by Holger Levsen
I wonder why you dont prefer a fixed timeline then. 6 *or* 12 months.

Mostly it doesn't seem to matter that much. :)

[Holger Levsen]

Post by Holger Levsen
aaaaah! Now I see that this is ment differently than it was proposed.

s#it#how I understood it#

[Bernd Zeimetz]

I agree with Holger that it's probably better to leave the amount of
time undefined, and see what happens on a case by case basis.

please let's not find a way to delay the next release forever.

[Simon Richter]

Hi,

Post by Russ Allbery
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.

I wonder if it would make sense to have a branching policy here: either use
systemd and declare it properly, or you follow the slow path.

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 in Debian either need no init integration
at all, or will be content with "start this at boot" and "start this at
that time", so they don't need anything beyond what is defined right now.

What's unclear right now is GTK's stance -- they seem to be interested in
using some new systemd features, which would make all GTK apps directly
dependent on systemd-as-pid1.

Simon

[Russ Allbery]

Post by Simon Richter
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 in Debian either need no init
integration at all, or will be content with "start this at boot" and
"start this at that time", so they don't need anything beyond what is
defined right now.

I don't really agree with this. I see numerous opportunities throught the
project in packages that have nothing to do with GNOME that would benefit
immensely from systemd features, particularly DynamicUser. There are also
more minor benefits in adopting the same mechanisms as other distributions
for doing similar things, such as tmpfiles.d. And there is the general
opportunity to move to a more declarative, configuration-driven syntax for
many things currently done via shell scripts, which will have small
advantages for thousands of packages.

I think we're not seeing those sorts of benefits right now because all
progress in this area apart from packages like GNOME that absolutely
require it has been on hold because of the challenging discussion
environment and general project uncertainty around systemd. We're
currently not taking advantage of a lot of really interesting
possibilities.

[Bernd Zeimetz]

Post by Ian Jackson
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.

For some systemd Features there is no sane route to implement them for a
non-systemd system. Especially all the security features, private
directories and so on. They will never catch up as it is technically
impossible or an enormous amount of work. So not haveing a route here is
perfectly fine.

[Russ Allbery]

Post by Bernd Zeimetz

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.

For some systemd Features there is no sane route to implement them for a
non-systemd system. Especially all the security features, private
directories and so on. They will never catch up as it is technically
impossible or an enormous amount of work. So not haveing a route here is
perfectly fine.

It's clearly *possible* to implement all of those security features
without systemd. There are standalone programs such as firejail that do
many of the same things. Even for features that really need PID 1 support
(which is rare for those sorts of security features), it's possible to add
that support to other init systems.

Obviously it's a very substantial amount of work, and one can be dubious
about whether that work will ever happen or if some community has the
resources required. The systemd project has attracted substantial
contributions and has written and tested a large amount of code, and
replicating that success will require a correspondingly large amount of
work.

But I think it's also important to note that this is (informed)
speculation about resourcing, rather than a hard technical constraint.

One very straightforward way that a non-systemd init system could
implement all of those things is to start by forking systemd and then
changing it to suit their differing objectives. No non-systemd init
system has yet taken that approach, but there's no inherent reason why
someone couldn't take that approach and rework the systemd code base to
use a different design.

[Bernd Zeimetz]

Post by Ian Jackson

Post by Sam Hartman
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.

I'll definitely orphan some packages when the Option 1 wins. Its just
not possible to maintain that init mess anymore for them.

But at the end the project decides, and if you don't like the outcome,
you can either live with it (see, nobody stops you from maintaining your
init scripts, Devuan might still exist so you can run your packages and
shipping a systemd unit in Debian is easy!) or decide to leave and work
somewhere else.

I think it is better to decide this issue and keep working on bugs
instead of keep discussing systemd vs init.

[Ian Jackson]

Post by Sam Hartman
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.

For the avoidance of doubt, can you please clarify whether "the last
amendment being accepted" includes amendments accepted by me, or by
Dmitry, and whether that depends on whether the option in question has
enough sponsors ? (You write "the last amendment being accepted" but
also "I accept an amendment".)

You can assume in your answer that no-one is engaging in a process of
deliberate delay by endless amendments. If that happens you can tell
us you think it is happening and set a new deadline.

Post by Sam Hartman
That said, if it looks like we need more time, I can always lengthen the
discussion period.

I would note that as the proposer of an option with enough seconds, I
can also call for a vote when the minimum discussion period has
elapsed. You can increase the minimum discussion period, but only to
3 weeks. IMO it would be quite appropriate for you to do that
immediately. After 3 weeks you would not be able to stop me calling
for a vote. I mention this for completeness, since it is entirely
hypothetical. I can't imagine me wanting to truncate the discussion
in such a way. I am happy to give the following commitment:

In any case I will not call for a vote without giving at least 4 days'
(96 hours') notice of my intent to do so.

Would you be willing to make a similar commitment ?

I am concerned in particular that Dmitry's slow email arrangements
mean that the process of developing his proposal, and getting seconds
for it, will be drawn out. This may make the process slower than
ideal but I think it is more important to get it right than to get it
done quickly.

Thanks,
Ian.

[Sam Hartman]

Ian> Sam Hartman writes ("Proposal: General Resolution on Init

Post by Sam Hartman
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.

To clarify, my understanding is that the discussion period started
November 16.
So, we're talking about a minimum discussion period expiring on
November 30.

I assumed the secretary would interpret the constitution differently and
that only the proposer of the original resolution could accept
amendments.
I seem to recall Manoj interpreted things that way back in the day.
So, at the time I wrote that text, I was under the mistaken belief that
I was the only one who could accept amendments. (I'm glad the secretary
has interpreted things differently.)

My assumption is still that only me accepting amendments resets the
minimum discussion period.
If that's not how the secretary sees things then I don't understand this
process at all and will need to have a re-read of the constitution and a
re-think about things.
I'm not making a value judgment about what the constitution should say,
just a judgment about past practice and my reading of the constitution.

Another way to understand what I intended is that I will do what I can
to keep the minimum discussion period ending at November 30.


That said, I'm very open to the idea of delaying calling for a vote if
people are finalizing wording that has received sufficient seconds or
for whichthe following two conditions are true:

1) People have indicated a desire to second if certain issues are
resolved;

2) It looks like there is a reasonable chance of resolving those issues


So, to be concrete. Right now, your proposal has received enough
support that I think it's worth trying to resolve outstanding amendments
before calling for a vote. (Although I also think we can probably do
that before November 30). Right now, I don't think Dmitry's proposal
has received enough support that I would want to delay to resolve
amendments. That could easily change in a week and a couple of days.

--Sam

[Russ Allbery]

Post by Sam Hartman
To clarify, my understanding is that the discussion period started
November 16.
So, we're talking about a minimum discussion period expiring on
November 30.

Your acceptance of my amendment reset the clock, at least by my reading of
the constitution. That happened on the 19th of November, so the two week
discussion period will now expire on the 3rd of December.

(This is actually a little bit murky since I didn't call for seconds and
you accepted the amendment directly. Procedurally, it looks like I
probably should have called for seconds to be in less ambiguous territory,
so we may need a secretarial ruling here.)

Post by Sam Hartman
I assumed the secretary would interpret the constitution differently and
that only the proposer of the original resolution could accept
amendments.
I seem to recall Manoj interpreted things that way back in the day.
So, at the time I wrote that text, I was under the mistaken belief that
I was the only one who could accept amendments. (I'm glad the secretary
has interpreted things differently.)

I believe this is a correct reading of the constitution. A.2.4 is
explicit that the minimum discussion period is from the last accepted
amendment, and A.1.3 is clear that amendments that have sufficient seconds
but are not agreed to by the proposer are not considered accepted
amendments.

(I also think this is a bug in the constitution; it means that a rejected
but seconded amendment can go on the ballot immediately before the vote
with no time for further discussion of that amendment, which seems
obviously poor. But that being said, fixing the constitution, if
appropriate, is a separate discussion.)

[Ian Jackson]

Post by Russ Allbery
(I also think this is a bug in the constitution; it means that a rejected
but seconded amendment can go on the ballot immediately before the vote
with no time for further discussion of that amendment, which seems
obviously poor. But that being said, fixing the constitution, if
appropriate, is a separate discussion.)

It would be really good if we could avoid this issue becoming
entangled in procedural disagreements.

To that end I think everyone involved, and particularly people like
Sam and me who have some kind of privileged role and might be able to
trigger constitutional clauses, should try to (i) exercise their
procedural rights consensually (whether those rights are disputed or
not) (ii) give explicit statements consenting to others' reasonable
procedural actions even when some or most readings of the constitution
wouldn't require it.

I certainly don't want to see this discussion drag on indefinitely.
But it is worth making sure everyone feels they (and their respective
communities) have been dealt with fairly, to avoid generating
bitterness which may last for years.

Ian.

[Sam Hartman]

Post by Sam Hartman
To clarify, my understanding is that the discussion period
started November 16. So, we're talking about a minimum
discussion period expiring on November 30.

Russ> Your acceptance of my amendment reset the clock, at least by
Russ> my reading of the constitution. That happened on the 19th of
Russ> November, so the two week discussion period will now expire on
Russ> the 3rd of December.

Russ> (This is actually a little bit murky since I didn't call for
Russ> seconds and you accepted the amendment directly.
Russ> Procedurally, it looks like I probably should have called for
Russ> seconds to be in less ambiguous territory, so we may need a
Russ> secretarial ruling here.)

I did?
I thought I told you I would accept the amendment.
It's my intent today or tomorrow to accept the amendment and to update
the discussion period to continue to expire on November 30.

[Russ Allbery]

Post by Sam Hartman
I did?
I thought I told you I would accept the amendment.
It's my intent today or tomorrow to accept the amendment and to update
the discussion period to continue to expire on November 30.

Oh, I see. Your message to debian-vote specifically was:

| I am in fact going to accept Russ's amendment clarifying division of
| responsibility.

which is a little ambiguous. I read it as accepting the amendment in that
message, but I can see that it probably meant you were going to do so at
some point in the future.

[Ian Jackson]

Post by Sam Hartman
It's my intent today or tomorrow to accept the amendment and to update
the discussion period to continue to expire on November 30.

I think a decision to shorten the minimum discussion period from the
constitutional default would be highly inappropriate. This is a
highly controversial issue which has existed for years and we are
intending here to resolve for the very long term. As Simon Richter
puts it, time spent now getting it right is time well spent.

Furthermore, Constitution 5.3:

The Project Leader should attempt to make decisions which are
consistent with the consensus of the opinions of the Developers.

I don't know why you think there is a consensus that this issue needs
to be dealt with promptly. All I can see here is several people
asking for more time.

Ian.

[Russ Allbery]

Post by Ian Jackson

Post by Sam Hartman
It's my intent today or tomorrow to accept the amendment and to update
the discussion period to continue to expire on November 30.

I think a decision to shorten the minimum discussion period from the
constitutional default would be highly inappropriate. This is a
highly controversial issue which has existed for years and we are
intending here to resolve for the very long term. As Simon Richter
puts it, time spent now getting it right is time well spent.

Sam said that he'd be willing to delay if needed if an additional proposal
received enough seconds to be on the ballot.

I think it's important that we hold this vote sufficiently clear of the
winter holidays that we don't run into trouble with low participation. To
me, that implies that the absolute latest we should start this vote is on
December 8th.

How about this compromise:

* Sam sets the conclusion of the discussion period to November 30th for
the current ballot, which would probably result in a vote starting on
December 1st (giving the Secretary some time to set up the vote). I
think the current ballot options are fairly stable.

* If any new proposal receives enough seconds to gain a slot on the ballot
by November 27th, Sam agrees that he will reset the discussion period to
end on somewhere between December 4th and 7th. (I personally would just
lock down the 7th for that contingency, but leaving this open in case
there's some reason I'm missing to end a bit earlier.) That will
provide at least an additional week to hammer out any remaining wording
problems with that option.

[Sam Hartman]

Post by Sam Hartman
It's my intent today or tomorrow to accept the amendment and to
update the discussion period to continue to expire on November
30.

Russ> Sam said that he'd be willing to delay if needed if an
Russ> additional proposal received enough seconds to be on the
Russ> ballot.

Russ> I think it's important that we hold this vote sufficiently
Russ> clear of the winter holidays that we don't run into trouble
Russ> with low participation. To me, that implies that the absolute
Russ> latest we should start this vote is on December 8th.

Russ> How about this compromise:

Russ> * Sam sets the conclusion of the discussion period to November
Russ> 30th for the current ballot, which would probably result in a
Russ> vote starting on December 1st (giving the Secretary some time
Russ> to set up the vote). I think the current ballot options are
Russ> fairly stable.

Russ> * If any new proposal receives enough seconds to gain a slot
Russ> on the ballot by November 27th, Sam agrees that he will reset
Russ> the discussion period to end on somewhere between December 4th
Russ> and 7th. (I personally would just lock down the 7th for that
Russ> contingency, but leaving this open in case there's some reason
Russ> I'm missing to end a bit earlier.) That will provide at least
Russ> an additional week to hammer out any remaining wording
Russ> problems with that option.

In general, I think you've approximately restated what I already said.
I'm not going to commit to a specific "compromise," because I think
there are some corner cases. As an example, if Dmitry's proposal got
five seconds tomorrow, I think we might still be in shape for a November
30 end of discussion.
I'd make that call sometime next week.
But in general, what you're talking about is very well aligned with my
thinking.

If on the other hand, Dmitry's proposal got enough seconds (or people
saying they planned to second the next version once it came out) next
week, delaying sometime between the 4th and 7th would seem to be more of
a requirement.

--Sam

[Kurt Roeckx]

Post by Russ Allbery

Post by Sam Hartman
To clarify, my understanding is that the discussion period started
November 16.
So, we're talking about a minimum discussion period expiring on
November 30.

Your acceptance of my amendment reset the clock, at least by my reading of
the constitution. That happened on the 19th of November, so the two week
discussion period will now expire on the 3rd of December.

I did not actually see him accepting that yet, just an intention
to do so.

Post by Russ Allbery
(This is actually a little bit murky since I didn't call for seconds and
you accepted the amendment directly. Procedurally, it looks like I
probably should have called for seconds to be in less ambiguous territory,
so we may need a secretarial ruling here.)

I don't see a reason for seconding something before you can
propose changes to it.

Post by Russ Allbery

Post by Sam Hartman
I assumed the secretary would interpret the constitution differently and
that only the proposer of the original resolution could accept
amendments.
I seem to recall Manoj interpreted things that way back in the day.
So, at the time I wrote that text, I was under the mistaken belief that
I was the only one who could accept amendments. (I'm glad the secretary
has interpreted things differently.)

I believe this is a correct reading of the constitution. A.2.4 is
explicit that the minimum discussion period is from the last accepted
amendment, and A.1.3 is clear that amendments that have sufficient seconds
but are not agreed to by the proposer are not considered accepted
amendments.
(I also think this is a bug in the constitution; it means that a rejected
but seconded amendment can go on the ballot immediately before the vote
with no time for further discussion of that amendment, which seems
obviously poor. But that being said, fixing the constitution, if
appropriate, is a separate discussion.)

That whole part could really use some fixing. The more you read
it, the more you think it says something else.


Kurt

[Ian Jackson]

Post by Kurt Roeckx
That whole part could really use some fixing. The more you read
it, the more you think it says something else.

Yes. I'm sorry about that. I have been thinking about these
matters. If the result of the GR doesn't put me off and I'm not
burned out, I may see if I can propose something to fix it.

Ian.

[Kurt Roeckx]

Post by Sam Hartman
Ian> Sam Hartman writes ("Proposal: General Resolution on Init

Post by Sam Hartman
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.

To clarify, my understanding is that the discussion period started
November 16.
So, we're talking about a minimum discussion period expiring on
November 30.
I assumed the secretary would interpret the constitution differently and
that only the proposer of the original resolution could accept
amendments.
I seem to recall Manoj interpreted things that way back in the day.
So, at the time I wrote that text, I was under the mistaken belief that
I was the only one who could accept amendments. (I'm glad the secretary
has interpreted things differently.)
My assumption is still that only me accepting amendments resets the
minimum discussion period.
If that's not how the secretary sees things then I don't understand this
process at all and will need to have a re-read of the constitution and a
re-think about things.
I'm not making a value judgment about what the constitution should say,
just a judgment about past practice and my reading of the constitution.
Another way to understand what I intended is that I will do what I can
to keep the minimum discussion period ending at November 30.

I always struggle with trying to understand that part, but my
current interpretation is different. The page shows the discussion
perriod starting at the 19th, which is when Ian's proposal got
enough sponsors.


Kurt

[Sam Hartman]

Kurt> I always struggle with trying to understand that part, but my
Kurt> current interpretation is different. The page shows the
Kurt> discussion perriod starting at the 19th, which is when Ian's
Kurt> proposal got enough sponsors.

My understanding is that you believe any formal amendment achieving
sufficient sponsors restarts the discussion period.
You may also believe that a sponsor of a formal amendment accepting a
change to that amendment resets the discussion period.
I argue below that is inconsistent with the constitution and introduces
significant strategic problems.



I claim that's bad on three grounds:

1) I assert that it is inconsistent with past practice.

I'll be happy to go on a dive and look at this issue in the past, but
I'm fairly sure we're diverging here from what we have done.

2) It is open to serious irreconcilable strategic abuse.
In particular, it means that any six developers can indefinitely block
us from voting by continuously introducing amendments and getting them
onto the ballot.
If it resets the discussion period each time that happens, then I see no
counter to that strategy.

(We can bring it up to 10 developers needed if you consider the counter
strategy of DAM expelling developers after they pull this a few times.)



3) I think it is textually inconsistent with the constitution.

To make this argument I'm going to make the argument that only the
proposer of a resolution can accept amendments.
That is, the person making a formal amendment is not a proposer of a
resolution in the sense of appendix A.1 (2).

I believe this is supported by the text.

Proposer defined (4.2 (1):
1. The Developers follow the Standard Resolution Procedure, below. A
resolution or amendment is introduced if proposed by any Developer
and sponsored by at least K other Developers, or if proposed by the
Project Leader or the Technical Committee.

That is, 4.2(1) acknowledges that both resolutions and amendments can be
proposed, but treats them separately.
A.1. Discussion and Amendment
Section A.1(1) discusses discussion:

1. Following the proposal, the resolution may be discussed. Amendments
may be made formal by being proposed and sponsored according to the
requirements for a new resolution, or directly by the proposer of
the original resolution.

Again, resolution and amendments are treated separately.


2. A formal amendment may be accepted by the resolution's proposer, in
which case the formal resolution draft is immediately changed to
match.

In this text an amendment may be accepted by the resolution's proposer.
No provision is made for an amendment to be accepted by an amendment's
proposer.

5. The proposer of a resolution may suggest changes to the wordings of
amendments; these take effect if the proposer of the amendment
agrees and none of the sponsors object. In this case the changed
amendments will be voted on instead of the originals.

This continues the trend of treating amendments separately from the
resolution.
That is, if amendments and resolutions were treated symmetrically, then
the text would talk about how proposers of amendments and the resolution
could suggest changes to amendments and the resolution.
Instead, this text goes out of its way to treat the categories
separately.
6. The proposer of a resolution may make changes to correct minor
errors (for example, typographical errors or inconsistencies) or
changes which do not alter the meaning, providing noone objects
within 24 hours. In this case the minimum discussion period is not
restarted.

Section A.2 (4) describes resetting the discussion period:

4. The minimum discussion period is counted from the time the last
formal amendment was accepted, or since the whole resolution was
proposed if no amendments have been proposed and accepted.

As a reminder, Section A.1(2) quoted above defines what it means for a
formal amendment to be accepted. That's something that happens when the
proposer of a resolution accepts an amendment and integrates it; it is
not something that happens when a formal amendment receives enough
sponsors to be on the ballot.


In conclusion, I think the text of the constitution is very clear that
a proposal achieving k sponsors does not reset the discussion period.
Interpreting things otherwise opens up a significant opportunity for
strategic abuse. I believe that it also is inconsistent with past
practice, although I have not substantiated that claim.

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

Unfortunately, under this interpretation, it is a lot less clear that
proposers of formal amendments can easily accept small changes to their
amendments without the cooperation of the proposer of the general
resolution.
Here's recommended interpretation to allow us to continue to do that
while be consistent with the closer examination of the text above:

Section 4.2 (5) and (6) seem to give us wide latitude in determining
what a sponsor is.

5. Proposals, sponsors, amendments, calls for votes and other formal
actions are made by announcement on a publicly-readable electronic
mailing list designated by the Project Leader's Delegate(s); any
Developer may post there.
6. Votes are cast by email in a manner suitable to the Secretary. The
Secretary determines for each poll whether voters can change their
votes.

I think it would be consistent with 4.2 (6) for the secretary to be able
to specify the form of a sponsorship and interpretations related to the
sponsorship, just as the secretary defines the manner in which votes
are cast.

My recommendation is that the secretary should consider that sponsorship
continues to apply to formal amendments when the proposer withdraws and
proposes a substantially similar amendment unless doing so is clearly
inconsistent with the text of the sponsorship.

[Kurt Roeckx]

Post by Sam Hartman
Kurt> I always struggle with trying to understand that part, but my
Kurt> current interpretation is different. The page shows the
Kurt> discussion perriod starting at the 19th, which is when Ian's
Kurt> proposal got enough sponsors.
My understanding is that you believe any formal amendment achieving
sufficient sponsors restarts the discussion period.
You may also believe that a sponsor of a formal amendment accepting a
change to that amendment resets the discussion period.
I argue below that is inconsistent with the constitution and introduces
significant strategic problems.

I already changed my mind. Like I said, I always struggle with it.

I'll try write something down of all the things I get confused
about later.


Kurt

[Kurt Roeckx]

Post by Kurt Roeckx

Post by Sam Hartman
Kurt> I always struggle with trying to understand that part, but my
Kurt> current interpretation is different. The page shows the
Kurt> discussion perriod starting at the 19th, which is when Ian's
Kurt> proposal got enough sponsors.
My understanding is that you believe any formal amendment achieving
sufficient sponsors restarts the discussion period.
You may also believe that a sponsor of a formal amendment accepting a
change to that amendment resets the discussion period.
I argue below that is inconsistent with the constitution and introduces
significant strategic problems.

I already changed my mind. Like I said, I always struggle with it.
I'll try write something down of all the things I get confused
about later.

There are various terms used, and they don't always seems to be
used in a consistent way. Here are the terms that I think are
relevant:
- resolution
- formal resolution draft
- draft resolution
- original resolution
- amendment
- proposal
- formal amendment
- accepting a formal amendment
- proposer of a resolution
- proposer of a formal amendment
- original proposer of an amendment
- proposer of the original resolution

Let's start with:
A.3. Voting procedure

1. Each resolution and its related amendments is voted on in a single
ballot that includes an option for the original resolution, each
amendment, and the default option (where applicable).

So there seems to be only 1 resolution on the ballot, which I guess is the
first option (which you've considered dropping), all the rest is
called an amendment. This makes me assume that the difference between
the resolution and the original resolution is that the text has been updated.

But then there is:
1. Following the proposal, the resolution may be discussed. Amendments
may be made formal by being proposed and sponsored according to the
requirements for a new resolution, or directly by the proposer of
the original resolution.

It seems there is a difference between the "proposer of the
resolution" and the "proposer of the original resolution". So
maybe resolution doesn't mean what we think it does, and we can
have multiple resolutions on the ballot?

It also introduces the concept of a formal amendment. It seems
that a formal amendment is one that's on the ballot, and either
has enough sponsors, or the proposer of the original resolution
can just say it's a good option to have on the ballot, and can
just add any other option, without requiring anybody to sponsor
it.

Then there is:
2. A formal amendment may be accepted by the resolution's proposer, in
which case the formal resolution draft is immediately changed to
match.

It seems that to update the resolution, it first needs to be made a formal
amendment, and then the resolution's proposer can accept it. But the proposer
of the original resolution can just make any amendment formal (1), and
then accept it (2).

Which brings us to:
5. The proposer of a resolution may suggest changes to the wordings of
amendments; these take effect if the proposer of the amendment
agrees and none of the sponsors object. In this case the changed
amendments will be voted on instead of the originals.
6. The proposer of a resolution may make changes to correct minor
errors (for example, typographical errors or inconsistencies) or
changes which do not alter the meaning, providing noone objects
within 24 hours. In this case the minimum discussion period is not
restarted.

It seems that once an amendments is formal, only the proposer of
the resolution can suggest changes. Can we make amendments to the
formal amendments?

Anyway, the reason this discussion was started was:
4. The minimum discussion period is counted from the time the last
formal amendment was accepted, or since the whole resolution was
proposed if no amendments have been proposed and accepted.

This all seems to depend on what "formal amendment was accepted"
means. I think it means that A.1.2 was used:
2. A formal amendment may be accepted by the resolution's proposer, in
which case the formal resolution draft is immediately changed to
match.

Which gets us back to what a formal resolution draft means, and I
have to wonder what the word draft there means.


Kurt

[Kurt Roeckx]

Post by Ian Jackson
I would note that as the proposer of an option with enough seconds, I
can also call for a vote when the minimum discussion period has
elapsed. You can increase the minimum discussion period, but only to
3 weeks. IMO it would be quite appropriate for you to do that
immediately. After 3 weeks you would not be able to stop me calling
for a vote. I mention this for completeness, since it is entirely
hypothetical. I can't imagine me wanting to truncate the discussion
In any case I will not call for a vote without giving at least 4 days'
(96 hours') notice of my intent to do so.

Note that any of the sponsors can also call for a vote.


Kurt

[Ansgar]

Post by Sam Hartman
Choice hartmans1: Affirm Init Diversity

[...]

Post by Sam Hartman
Init scripts are the lowest common denominator across all init
systems.

I think naming options "Init diversity" isn't really expressive: if
current options "A" and "E" are called "Affirm Init Diversity" or "Init
Diversity", does that mean "Option D" is against "Init Diversity"?

I've got no better idea, but there should be a bit more to distinguish
the proposals.

Post by Sam Hartman
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.

I don't think this is really what we might want: when there are
multiple competing options, Debian-specific or not, developed under the
systemd umbrella or not, which on Debian packagers decide to use should
only be on merit, i.e. there shouldn't be an implicit "we choose
systemd by default".

Aspects like "Debian-specific" or "already adopted by other
distributions" are fair points for comparison, but whether a given
program is developed under the umbrella of systemd or not doesn't
really matter.

I believe we are mostly thinking of systemd-tmpfiles or -sysusers here
which do have a "Debian-specific (and currently imperative)" and
"systemd-provided" implementation, but as a slightly different example
consider resolved / unbound: here one is systemd-provided, but the
other non-Debian-specific. But there is no inherit advantage of
"resolved" over "unbound" just because it is developed as part of
systemd.

What does matter to me is that we don't block the idea to use
facilities like systemd-tmpfiles or -sysusers on Linux just on grounds
of them being developed under the umbrella of the systemd project, and
that we don't create barriers that don't exist for other developments
such as arbitrary requirements for Policy inclusion just on grounds of
something developed in a specific upstream Git repository when these
barriers don't exist for comparable facilities provided by a different
upstream project (as Option D would introduce).

This affects both this paragraph and the name of the option.

So a try to better reflect that idea:

```
Choice 3: Affirm systemd as preferred init system; allow tooling
evolution

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. [No change here.]

The project commits to open evolution of tooling in the future.
This explicitly includes the possible adoption of facilities
provided under the systemd project umbrella such as systemd-tmpfiles
or systemd-sysusers if such facilities are considered useful and
the preferred available implementation. The project recognizes this
might create additional work for, for example, non-Linux ports, but
believes this alone should not be considered a blocker for adoption.

[Following paragraphs as before]
```

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

Besides non-Linux ports I don't see why one would want an alternative
for programs like the ones mentioned above?

In addition this seems to overlap with the last paragraph below, but
here we talk about "alternatives to other interfaces" and below not.
So maybe just have the last paragraph and merge the "alternatives" in
there? But I have only a very weak opinion on this.

Post by Sam Hartman
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.

```
Packages may include support for alternate init systems and/or
other facilities as mentioned above besides systemd. Maintainers
use their normal procedures for deciding which patches to include.
```

Ansgar

[Russ Allbery]

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.

I don't think this is really what we might want: when there are multiple
competing options, Debian-specific or not, developed under the systemd
umbrella or not, which on Debian packagers decide to use should only be
on merit, i.e. there shouldn't be an implicit "we choose systemd by
default".

This is the reason why I put "supported by the systemd maintainers" here,
although that may not be sufficient to address your concern. But the idea
I had in mind was that the decision of whether to support the systemd
facility would be an informed choice that takes into account concerns like
that. I know there are some systemd facilities that the systemd
maintainers in Debian have little desire to support as an archive-wide
default.

I believe we are mostly thinking of systemd-tmpfiles or -sysusers here
which do have a "Debian-specific (and currently imperative)" and
"systemd-provided" implementation, but as a slightly different example
consider resolved / unbound: here one is systemd-provided, but the other
non-Debian-specific. But there is no inherit advantage of "resolved"
over "unbound" just because it is developed as part of systemd.

This is probably out of scope for this paragraph because a stub resolver
is not Debian-specific nor do we choose just one. The only thing that
might be in scope is a discussion of what stub resolver to use by default,
but the existing practice of not running a stub resolver has some obvious
advantages (thus triggering that last clause).

```
Choice 3: Affirm systemd as preferred init system; allow tooling
evolution
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. [No change here.]
The project commits to open evolution of tooling in the future.
This explicitly includes the possible adoption of facilities
provided under the systemd project umbrella such as systemd-tmpfiles
or systemd-sysusers if such facilities are considered useful and
the preferred available implementation. The project recognizes this
might create additional work for, for example, non-Linux ports, but
believes this alone should not be considered a blocker for adoption.
[Following paragraphs as before]
```

I don't really know what "commits to open evolution of tooling" means. I
think what you're trying to say is that the project will make decisions
about standardized tooling on the basis of their technical merits for a
systemd install rather than their portability to non-systemd systems?

[Ansgar]

Post by Russ Allbery

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.

I don't think this is really what we might want: when there are multiple
competing options, Debian-specific or not, developed under the systemd
umbrella or not, which on Debian packagers decide to use should only be
on merit, i.e. there shouldn't be an implicit "we choose systemd by
default".

This is the reason why I put "supported by the systemd maintainers" here,
although that may not be sufficient to address your concern. But the idea
I had in mind was that the decision of whether to support the systemd
facility would be an informed choice that takes into account concerns like
that.

It's mostly that it pushes systemd preference a bit more than my
preference, mostly because the short text also reads "Focus on systemd
for [...] other facilities", but I have no preference for systemd over
other implementations for "other facilities".

I see value in cross-distribution collaboration which might be an
advantage of solutions developed under the systemd umbrella, but that's
not inherent so: it's the same for any other non-Debian specific
implementation.

Debian-specific solutions of course are also still fine if we believe
these to be the best fit to our needs.

Ansgar

[Russ Allbery]

Post by Ansgar
It's mostly that it pushes systemd preference a bit more than my
preference, mostly because the short text also reads "Focus on systemd
for [...] other facilities", but I have no preference for systemd over
other implementations for "other facilities".
I see value in cross-distribution collaboration which might be an
advantage of solutions developed under the systemd umbrella, but that's
not inherent so: it's the same for any other non-Debian specific
implementation.
Debian-specific solutions of course are also still fine if we believe
these to be the best fit to our needs.

Yeah, this is all a good point. I *think* it would work out the same in
practice, but there's definitely a good argument to be made for toning it
down a little to better reflect what I think the viewpoint is of systemd
proponents. I think the median view of that perspective is closer to
yours (use the things that make sense taking into account
cross-distribution compatibility and other advantages) than to "prefer
systemd across the board."