Differences between revisions 12 and 13
Revision 12 as of 2013-10-26 01:05:15
Size: 3316
Editor: ?SteveLangasek
Comment: another pro point
Revision 13 as of 2013-10-26 01:11:32
Size: 4116
Editor: ?SteveLangasek
Comment: face the CLA problem
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * Upstart is covered be a [[http://www.canonical.com/contributors|copyright license agreement]], which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the package itself; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL and would be no worse off than we are today with a sysvinit package that also has no upstream.

This page documents the position statement of individuals who suggest that Debian should adopt upstart as the default init system. Before editing this page, please see the instructions on how debates work. If you are not the maintainer of a position statement, and have a suggestion or change to make, please contact the maintainer.

Upstart Position Statement

Upstart is a modern, well-tested, event-based init system. It is used on tens or hundreds of millions of servers, desktops, cloud instances and embedded systems throughout the world. Debian should adopt it as the default init system for the jessie release.

Pros

  • Upstart brings significant new functionality to init, using a simple, declarative job configuration format (described here) that removes the need to maintain init scripts written in shell as "configuration files". Changes to job configuration can be maintained in separate .override files, or as changes directly to .conf files that are straightforwardly diffable/mergeable on upgrades.

  • Upstart supports backwards-compatibility. It is straightforward to include an /etc/default/foo file in an upstart job if needed (though this is not the recommended configuration method where sysvinit compatibility is not required). Existing init scripts will continue to run. insserv dependency relationships between init scripts are respected, providing a smooth transition to upstart from sysvinit.

  • Upstart has been tested in battle. Two consecutive long-term supported releases of Ubuntu have shipped with native upstart job support, giving Ubuntu an opportunity to shake out all the bugs so that Debian doesn't have to. The work to integrate upstart support from Ubuntu into Debian is straightforward.
  • Upstart fixes bugs. There are many longstanding race conditions in the existing sysvinit startup sequence that cause problems in complex disk/network configuration scenarios. These problems have been solved in the upstart rollout on Ubuntu, Debian will not have to reinvent the wheel.
  • Upstart welcomes ports. Lack of support for non-Linux ports has been a concern in all of the discussions about changing Debian's default init system. Upstart upstream has expressed their interest in having ports to Hurd and kFreeBSD, so that a decision to adopt Upstart does not mean maintaining compatibility with two init systems in Debian indefinitely.
  • Upstart is elegant. The code is easy to read, making it easier to debug and modify. It uses libnih, the best C utility library around (beats the pants off of glib for code clarity by leveraging current C standards and relevant gcc extensions).
  • Upstart is tested code. There is a thorough upstream test suite that is run at package build time. The test suite is twice the size of the code itself.
  • Upstart is actively maintained. Canonical continues to develop upstart as an active upstream project, responding to the evolving needs of its users.

Cons

  • Upstart is covered be a copyright license agreement, which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the package itself; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL and would be no worse off than we are today with a sysvinit package that also has no upstream.

Upstart vs. SysVinit

Upstart vs. SystemD

Position Statement Maintainers

Comments