Kurt, I'd like to accept Russ's amendment to choice hartmans1. Attached please find a complete replacement for all three choices, although only hartmans1 has changed. Also, please find a diff in case that's easier for you. Using powers under constitution 5.1 (8), I vary the minimum discussion period so that the minimum discussion period ends on November 30. My inten here is to accept the amendment without resetting the minimum discussion period. Version 2e62d001f ---------------------------------------- Choice hartmans1: Affirm Init Diversity 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. 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 says that packages must not include a service unit without an init script. Policy editors are requested to amend policy; a package including a service unit should include an init script (meaning that not doing so is considered a bug), but this is not required (meaning that it is not a serious bug). However, adding an init script to such a package is appropriate for a non-maintainer upload. Policy editors are requested to consider whether there are cases where packages must not remove an init script that used to be provided because it would break a system on upgrade. The release team is requested to consider whether there are cases where removing an init script should be a release-critical bug for the same reason. 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-serious) 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 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. 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 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. 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. ---------------------------------------- diff --git a/init-system-gr b/init-system-gr index e0d5ee2..ca9723d 100644 --- a/init-system-gr +++ b/init-system-gr @@ -22,15 +22,20 @@ 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. +units in addition to init scripts. Current policy says that packages must not 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. + +Policy editors are requested to amend policy; a package including a +service unit should include an init script (meaning that not doing so is +considered a bug), but this is not required (meaning that it is not a +serious bug). However, adding an init script to such a package is +appropriate for a non-maintainer upload. Policy editors are requested to +consider whether there are cases where packages must not remove an init +script that used to be provided because it would break a system on +upgrade. The release team is requested to consider whether there are +cases where removing an init script should be a release-critical bug for +the same reason. Once the community of users of an alternate init system have said that a solution is sufficiently functional for them, others should not @@ -46,10 +51,10 @@ 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. +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-serious) 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
Attachment:
signature.asc
Description: PGP signature