Re: Proposal: General Resolution on Init Systems and systemd Facilities
On November 14, 2019 8:08:28 PM UTC, Sam Hartman <leader@debian.org> 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 to: