On Thu, 05 Dec 2019 11:59:36 +0000, Ian Jackson wrote: > Here is the formal version of this proposal. (My previous mail wasn't > signed.)
Thank you. > Title: Support portability, without blocking progress > > PRINCIPLES > > 1. The Debian project reaffirms its commitment to be the glue that > binds and integrates different software that provides similar or > equivalent functionality, with their various users, be them humans or > other software, which is one of the core defining traits of a > distribution. > > 2. We consider portability to different hardware platforms and > software stacks an important aspect of the work we do as a > distribution, which makes software architecturally better, more robust > and more future-proof. > > 3. We acknowledge that different upstream projects have different > views on software development, use cases, portability and technology > in general. And that users of these projects weight tradeoffs > differently, and have at the same time different and valid > requirements and/or needs fulfilled by these diverse views. > > 4. Following our historic tradition, we will welcome the integration > of these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our > distribution, by reconciling these conflicts via technical means, as > long as there are people willing to put in the effort. > > 5. This enables us to keep serving a wide range of usages of our > distribution (some of which might be even unforeseen by us). From > servers, to desktops or deeply embedded; from general purpose to very > specifically tailored usages. Be those projects hardware related or > software based, libraries, daemons, entire desktop environments, or > other parts of the software stack. > > SYSTEMD DEPENDENCIES > > 6. Ideally, packages should be fully functional with all init systems. This > means (for example) that daemons should ship traditional init scripts, or use > other mechanisms to ensure that they are started without systemd. It also > means > that desktop software should be installable, and ideally fully functional, > without systemd. > > 7. So failing to support non-systemd systems, where no such support is > available, is a bug. But it is *not* a release-critical bug. Whether the > requirement for systemd is recorded as a formal bug in the Debian bug system, > when no patches are available, is up to the maintainer. > > 8. When a package has reduced functionality without systemd, this should not > generally be documented as a (direct or indirect) Depends or Recommends on > systemd-sysv. This is because with such dependencies, installing such a > package > can attempt to switch the init system, which is not what the user wanted. For > example, a daemon with only a systemd unit file script should still be > installable on a non-systemd system, since it could be started manually. > > One consequence of this is that on non-systemd systems it may be possible to > install software which will not work, or not work properly, because of an > undeclared dependency on systemd. This is unfortunate but trying to switch the > user's init system is worse. We hope that better technical approaches can be > developed to address this. > > 9. We recognise that some maintainers find init scripts a burden and we hope > that the community is able to find ways to make it easier to add support for > non-default init systems. Discussions about the design of such systems should > be friendly and cooperative, and if suitable arrangements are developed they > should be supported in the usual ways within Debian. > > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > 10. Failing to support non-systemd systems when such support is available, or > offered in the form of patches (or packages), *should* be treated as a release > critical bug. For example: init scripts *must not* be deleted merely because a > systemd unit is provided instead; patches which contribute support for other > init systems (with no substantial effect on systemd installations) should be > filed as bugs with severity `serious'. > > This is intended to provide a lightweight but effective path to ensuring that > reasonable support can be provided to Debian users, even where the > maintainer's > priorities lie elsewhere. (Invoking the Technical Committee about individual > patches is not sensible.) > > If the patches are themselves RC-buggy (in the opinion of, initially, the > maintainer, and ultimately the Release Team) then of course the bug report > should be downgraded or closed. > > 11. Maintainers of systemd components, or other gatekeepers (including other > maintainers and the release team) sometimes have to evaluate technical > contributions intended to support non-systemd users. The acceptability to > users > of non-default init systems, of quality risks of such contributions, is a > matter for the maintainers of non-default init systems and the surrounding > community. But such contributions should not impose nontrivial risks on users > of the default configuration (systemd with Recommends installed). > > NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES > > 12. systemd provides a variety of facilities besides daemon startup. For > example, creating system users or temporary directories. Current Debian > approaches are often based on debhelper scripts. > > In general more declarative approaches are better. Where > > - systemd provides such facility > - a specification of the facility (or suitable subset) exists > - the facility is better than the other approaches available in Debian, for > example by being more declarative > - it is reasonable to expect developers of non-systemd systems including > non-Linux systems to implement it > - including consideration of the amount of work involved > > the facility should be documented in Debian Policy (by textual incorporation, > not by reference to an external document). The transition should be smooth for > all users. The non-systemd community should be given at least 6 months, > preferably at least 12 months, to develop their implementation. (The same goes > for any future enhancements.) > > If policy consensus cannot be reached on such a facility, the Technical > Committee should decide based on the project's wishes as expressed in this GR. > > BEING EXCELLENT TO EACH OTHER > > 13. In general, maintainers of competing software, including maintainers of > the > various competing init systems, should be accommodating to each others' needs. > This includes the needs and convenience of users of reasonable non-default > configurations. > > 14. Negative general comments about software and their communities, including > both about systemd itself and about non-systemd init systems, are strongly > discouraged. Neither messages expressing general dislike of systemd, nor > predictions of the demise of non-systemd systems, are appropriate for Debian > communication fora; likewise references to bugs which are not relevant to the > topic at hand. > > Communications on Debian fora on these matters should all be encouraging and > pleasant, even when discussing technical problems. We ask that communication > fora owners strictly enforce this. > > 15. We respectfully ask all Debian contributors including maintainers, Policy > Editors, the Release Team, the Technical Committee, and the Project Leader, to > pursue these goals and principles in their work, and embed them into documents > etc. as appropriate. (This resolution is a position statement under s4.1(5).) Seconded. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Dire Straits: Setting Me Up
signature.asc
Description: Digital Signature
