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.
Attachment:
signature.asc
Description: PGP signature