[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Last minute cominbations G+D and/or G+E

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
> 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.
> 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.
> 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).
> 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.
> 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).)



 .''`.  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

Attachment: signature.asc
Description: Digital Signature

Reply to: