make more nominees plural
[collab-maint/debian-ctte.git] / 727708_initsystem / draft-resolution-iwj.txt
1 Rubric:
2
3 0. We decide as follows (Constitution 6.1(1),(2)).  Text in square
4    brackets "[]" is non-binding advice (Constitution 6.1(5)).  We
5    require the Policy Editors (Constitution 6.1(1)) to make the policy
6    changes they think appropriate to give effect to this resolution.
7
8 Choice of init system:
9
10 1. The default init(1) in jessie for Linux architectures will be
11    upstart.
12
13 2. The default init(1) in jessie for non-Linux ports will be upstart
14    if it has been ported and confirmed by the porters to be working by
15    the time of the jessie release.  Failing this, the default init(1)
16    in jessie for non-Linux ports is left to the discretion of the
17    maintainers of that port.
18
19    [ However, the Technical Committee requests that, should upstart be
20    unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD
21    porters agree on a single alternative init(1) implementation that
22    will be shared by both ports. ]
23
24    [ Non-use of upstart should not be a criterion for architecture
25    qualification status in jessie. ]
26
27 3. At least in jessie, unless a satisfactory compatibility approach is
28    developed and deployed (see paragraph 10), packages must continue
29    to provide sysvinit scripts.  Lack of a sysvinit script (for a
30    daemon which contains integration with at least one other init
31    system) is an RC bug in jessie.
32
33    Likewise, packages must not Depend on or Recommend (directly or
34    indirectly) a specific init(1).  Violations of this are also an RC
35    bug in jessie.
36
37    Theses rules do not apply to machinery which itself forms part of
38    the implementation of one or more init systems.
39
40    [ After jessie, the policy editors may drop this requirement;
41    perhaps entirely, or perhaps in favour of a requirement to provide
42    at least one of sysvinit or systemd integration.  The policy
43    editors may wish to refer this decision to us in due course. ]
44
45 Policy is not ready, so hold off on updating all packages:
46
47 4. [ The current Debian policy for upstart, in the policy manual,
48    could do with some improvement and enhancement.  The current Debian
49    policy for systemd needs to be finished and agreed, and then
50    incorporated in the policy manual.  We encourage the maintainers of
51    upstart and systemd, and others, to submit relevant policy
52    enhancements.
53
54    Contributors who have not already added native support for upstart,
55    systemd, or OpenRC may wish to wait until the relevant Debian
56    Policy is declared, by the Policy editors, to be ready.  Early
57    adopters should be aware that the requirements may change and their
58    packages may require updates. ]
59
60 Support requirements for packages:
61
62 5. Subject to paragraphs 4 and 6 of this resolution, packages should
63    provide native upstart jobs where relevant.
64
65    Lack of native upstart support is not a release-critical bug for
66    jessie.
67
68    [ Patches for upstart support should be treated the way "release
69    goals" have been treated in the past; so, for example, there should
70    be a low NMU threshold for patches meeting suitable criteria.
71
72    The Debian Project Leader and/or applicable Delegates should give
73    effect to this part of our decision. ]
74
75 6. [ Maintainers should accept reasonable patches for native upstart,
76    systemd and openrc support.
77
78    A. A reasonable patch:
79     (i) is proposed after the relevant policy is finalised;
80     (ii) complies with that policy;
81     (iii) complies with the advice and requirements in this
82         resolution; and
83     (iv) takes the approaches to integration chosen by upstream,
84         or failing that by the Debian maintainer.
85
86    B. A patch is not unreasonable just because:
87     (i) the package upstream (or the Debian maintainer) does not wish
88         to support the relevant init system at all; or
89     (ii) they do not wish to support any of the suitable non-forking
90         startup protocols offered by that init system.
91
92    C. However, a maintainer is entitled to consider a patch unreasonable
93       if it:
94     (i) Requires additional build-dependencies; or
95     (ii) Requires additional runtime dependencies except sysv-rc; or
96     (iii) Introduces other than trivial new code into the daemon; or
97     (iv) "Abuses" SIGSTOP as done by the upstart "expect stop"
98       protocol and as disliked by the systemd community.
99
100    Code to write to an already-open fd and close it, or to raise a
101    signal, will usually be trivial for these purposes.  (This includes
102    enabling the new protocol via command-line switches or environment
103    variable tests, and removing any small fixed set of associated
104    variables from the environment.)  Code to connect to an AF_UNIX
105    socket and send a message will not usually be considered trivial.
106
107    We are aware that at present it is not possible to provide a patch
108    for any of systemd's or upstart's main non-forking daemon startup
109    readiness protocols which is necessarily reasonable by this
110    definition.
111
112    Therefore if the upstart and systemd communities in Debian want the
113    widest adoption in the project, these problems should be addressed
114    by changes to the upstart and systemd package to widen their
115    support for different startup protocols.  Ideally each init should
116    in any case provide support for the main protocols supported by
117    their competition.
118
119    Failure to apply reasonable patches, including failure to explain
120    promptly and constructively why a patch is not reasonable, is
121    likely to lead to the maintainer being overruled. ]
122
123 Detailed policy specifications:
124
125 7. [ No package in Debian should use "expect fork" or "expect daemon"
126    in upstart jobs.  The corresponding code in upstart may be disabled
127    or compiled out on some or all architectures. ]
128
129 8. Policy rules for support for init systems must:
130
131    (a) Specify the use of a non-forking startup protocol (for
132        upstart and systemd),
133
134    (c) Require that environment variables and fds involved in the
135        daemon startup protocol should not in general be inherited by
136        the daemon's descendants.
137
138    (d) Forbid the introduction of embedded copies of library code
139        (or the use of any embedded copies included by upstream).
140
141 9. [ Policy should provide non-binding suggestions to Debian
142    contributors who are converting daemons to upstart and/or systemd,
143    for example:
144
145    (a) If changes are necessary to the core daemon code, make those
146        changes acceptable to the daemon's upstream if possible.
147
148    (b) It is fine to introduce new code in the main body of the daemon
149        to support non-forking startup, socket activation or readiness
150        signalling.
151
152    (c) Support for upstart is usually best provided with the
153        raise(SIGSTOP) non-forking daemon readiness protocol, unless
154        and until a better protocol is available.
155
156    (d) It is fine to introduce new command-line options to request the
157        new startup mode(s), or to honour additional
158        init-system-specific environment variables to request the new
159        startup mode(s). ]
160
161 Cross-init-system compatibility:
162
163 10. Debian contributors are encouraged to explore and develop ways in
164    which a package can provide support for non-forking startup in
165    multiple different init systems without having to have separate
166    support for each init system in the source package; and, ideally,
167    without having to have separate support for each init system in the
168    binary package.
169
170 Replacement of existing functionality - process:
171
172 11. [ Sometimes it is proposed that a package should take over some
173    function currently performed by an existing different package.
174
175    In such cases, the consent of the maintainers of the the package
176    currently providing the functionality should be sought, or failing
177    that, consensus obtained from the project as a whole in the usual
178    way.
179
180    This discussion should ideally take place before implementation
181    work starts on the proposed replacement.  If and when the change is
182    agreed, it should be accompanied by the appropriate policy changes.
183
184    It is not proper for anyone declare an existing program obsolete,
185    simply on the grounds that they have planned or implemented a
186    replacement (whether as part of an existing codebase or otherwise).
187
188    These principles apply regardless of whether the proposed new
189    implementation provides the functionality via a reimplementation of
190    the existing interface, or via a wholly new interface. ]