-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ian Jackson writes ("Re: Last minute cominbations G+D and/or G+E"):
> Here is what I think Guillem's plus mine looks like.
>
> NB that I may have reintroduced typos which have been fixed on the
> website version. I haven't had time to check that.
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).)
- --
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
-----BEGIN PGP SIGNATURE-----
iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAl3o8RwgHGlqYWNrc29u
QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTlHdAf+JAAuZLrEmzDg
xgFlIKK7nxGabVx1j1LDbP7xnyCv2HOOI9KQfONE/zeuRu4+r2OHNC131LXDl1Om
9pS1N3bQrW5OfQQTHvU+ESM8J+H1UT6EPAZEkNkkDoKTdvlA0NB47pfWjYY5o8tB
T4LkXLcMkccPypOcNjVTN6hbzyL/Krw4CTbkJHSxD3tCRW+nLMLLDLVdAgdE9DMG
gONiU2XE4LonyVhOysWjTDTDYOKpyq0Jo3UmQsf2mrF0cNH3tQDuRpdLZJeb9W1e
hhGdsJmp912oRLyrhGLxqvfOnxWHFp/y4kwKShSAcCfEKeievz+4gLeunYMZDOf8
wHeOyLQSOg==
=l2yV
-----END PGP SIGNATURE-----
