On Thu, Dec 05, 2019 at 11:59:36AM +0000, Ian Jackson wrote:
> Here is the formal version of this proposal. (My previous mail wasn't
> signed.)
>
> I hereby propose it and hope to have it on the ballot, given that
> there are enough seconds. I do *not* intend to replace the existing
> proposal D.
>
>
> Differences from the version I posted yesterday:
> * Added a title
> * Typos and grammar fixes
> * Numbering fixed
>
> Kurt, you can make the HTML for this as follows:
> * c&p the HTML from proposal D
> * Adding the new title
> * Replacing the PRINCIPLES section by c&p the text
> from G, and numbering the paragraphs as clauses
> * Renumbering (adding 3 to each clause number)
>
> (I constructed this by dumping the w3m of D from the vote page and
> reconciling all the output from `git diff --color --word-diff'.)
>
>
> For the avoidance of any doubt, if we can get this onto the ballot I
> intend to rank it ahead of my own D.
>
> Nevertheless I want to retain my existing D because its weaker
> statement of principles may well be attractive to a wider audience,
> because it was a negotiated compromise which had input from a variety
> of people with different opinions, and because there is not time now
> to find out whether the people who supported D would prefer this one.
>
> Thanks,
> Ian.
>
>
> 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).)
signed.
--
cheers,
Holger
-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Attachment:
signature.asc
Description: PGP signature