727708: my draft resolution, wip

diff --git a/727708_initsystem/draft-resolution-iwj.txt b/727708_initsystem/draft-resolution-iwj.txt
new file mode 100644 (file)
index 0000000..cc827f5
--- /dev/null
+++ b/727708_initsystem/draft-resolution-iwj.txt
@@ -0,0 +1,137 @@
+1. The default init(1) in jessie should be upstart.
+
+2. General requirements for new init system support patches
+
+   (We observe and advise:)
+
+   Patches to update a package to support a new init system should:
+   (a) use a non-forking startup protocol;
+   (b) not introduce additional build-dependencies;
+   (c) not introduce additional runtime dependencies;
+   (d) not introduce substantial amounts of new code into
+       the daemon (code to connect to an AF_UNIX socket and send
+       a message counts as substantial; code to write to an
+       already-open fd, or raise a signal, does not);
+   (e) not introduce embedded copies of library code;
+   (f) if changes are necessary to the core daemon code, make those
+       changes acceptable to the daemon's upstream if possible;
+   (g) use the startup protocol chosen by the upstream maintainer
+       or failing that the Debian maintainer, subject to (a)..(f);
+   (h) not introduce significant amounts of hard-coded boilerplate
+       in package maintainer scripts or rules files;
+   (i) use facilities documented in the reference manuals for the
+       init system in question (as found in sid);
+
+   Such patches might well (and probably often will):
+   (m) introduce new code in the main body of the daemon to support
+       non-forking startup, socket activation or readiness signalling,
+       including in particular the upstart raise(SIGSTOP) protocol;
+   (n) introduce new command-line options to request the new
+       startup mode(s);
+   (o) honour additional environment variables to request the
+       new startup mode(s);
+   (p) introduce new code to remove such environment variables
+       from the environment of the daemon's descendants;
+   (q) introduce new debhelper calls (or handwritten rules code,
+       if that's how the rules file is structured already) to
+       place the relevant files in the binary package and
+       perhaps relevant runes in the maintainer scripts.
+
+   (The TC directs the policy editors:)
+
+   Policy should be amended to reflect the advice given in 2(a)..(e)
+   above.  ((f)..(i) are thought obvious or out of scope for policy.)
+
+2. Maintainer receptiveness to patches
+
+   (We observe and advise:)
+
+   The Debian maintainer for a daemon package should apply any
+   submitted reasonable patches to provide native upstart or systemd
+   support (or to convert existing upstart or systemd support to a
+   non-forking startup protocol).
+
+   This is provided that these patches meet the criteria (a)..(i)
+   above.  That such patches have the features described in (m)..(q)
+   above should not be regarded as blockers for acceptance.
+
+   Failure to deal with patches in a constructive way is likely to
+   lead to a decision by the TC to overrule the maintainer.
+
+3. Requirement to support upstart
+
+   (We decide, pursuant to the referral of the init system decision to
+   us, that:)
+
+   Packages should provide native upstart jobs where relevant.
+
+   Patches for upstart support should be treated analogous to the way
+   "release goals" have been treated in the past: so, for example,
+   they should have a low NMU threshold.
+
+   Lack of native upstart support is not a release-critical bug
+   for jessie.
+
+4. Cross-init system compatibility
+
+   (We observe and advise:)
+
+   Debian contributors are encouraged to explore and develop ways in
+   which a package can provide support for multiple different init
+   systems without having to have separate support for each init
+   system in the source package; and, ideally, without having to have
+   separate support for each init system in the binary package.
+
+4. Requirement to support other systems
+
+   (We decide, pursuant to the referral of the init system decision to
+   us, that:)
+
+   At least in jessie, unless a satisfactory approach to (3) is
+   developed and deployed, packages must continue to provide sysvinit
+   scripts.
+
+   After jessie, the policy editors may drop this requirement; either
+   entirely, or in favour of a requirement to provide at least one of
+   sysvinit or systemd integration.
+
+5. Policy for new init systems
+
+   (We advise:)
+
+   The current Debian policy for upstart, in the policy manual, could
+   do with some improvement and enhancement.
+
+   The current Debian policy for systemd needs to be finished and
+   agreed, and then incorporated in the policy manual.
+
+   We encourage the maintainers of upstart and systemd, and others, to
+   submit relevant policy enhancements.
+
+6. Replacement of existing functionality
+
+   (We observe and advise:)
+
+   Sometimes it is proposed that a package should take over some
+   function currently performed by an existing different package.
+
+   In such cases, the consent of the maintainers of the the package
+   currently providing the functionality should be sought, or failing
+   that, consensus obtained from the project as a whole in the usual
+   way.
+
+   This discussion should ideally take place before implementation
+   work starts on the proposed replacement.  If and when the change is
+   agreed, it should be accompanied by the appropriate policy changes.
+
+   It is not proper for anyone declare an existing program obsolete,
+   simply on the grounds that they have planned or implemented a
+   replacement (whether as part of an existing codebase or otherwise).
+
+   These principles apply regardless of whether the proposed new
+   implementation provides the functionality via a reimplementation of
+   the existing interface, or via a wholly new interface.
+
+7. Startup protocol improvement
+
+   We encourage upstart and systemd