Bonjour,
Bonjour, Le 01/12/2019 à 12:51, JP Guillonneau a écrit :Bonjour, relecture de la version française. Amicalement. -- Jean-PaulVoici une version avec les corrections de Baptiste et de Jean-Paul.
Ajout d'une nouvelle version avec une nouvelle proposition qui est un assemblage de plusieurs propositions. Le texte original se trouve ici : https://salsa.debian.org/webmaster-team/webwml/blob/master/english/vote/2019/vote_002.wml
Merci d'avance pour vos nouvelles relectures.
Amicalement,
jipege
#use wml::debian::translation-check translation="b5d828ca55f6037ee7cfa117083df0f160a9521b" maintainer="Jean-Pierre Giraud"
<define-tag pagetitle>Résolution générale : les systèmes de démarrage et systemd</define-tag>
<define-tag status>D</define-tag>
# meanings of the <status> tag:
# P: proposed
# D: discussed
# V: voted on
# F: finished
# O: other (or just write anything else)
#use wml::debian::template title="<pagetitle>" BARETITLE="true" NOHEADER="true"
#use wml::debian::toc
#use wml::debian::votebar
<h1><pagetitle></h1>
<toc-display />
# The Tags beginning with v are will become H3 headings and are defined in
# english/template/debian/votebar.wml
# all possible Tags:
# vdate, vtimeline, vnominations, vdebate, vplatforms,
# Proposers
# vproposer, vproposera, vproposerb, vproposerc, vproposerd,
# vproposere, vproposerf
# Seconds
# vseconds, vsecondsa, vsecondsb, vsecondsc, vsecondsd, vsecondse,
# vsecondsf, vopposition
# vtext, vtextb, vtextc, vtextd, vtexte, vtextf
# vchoices
# vamendments, vamendmentproposer, vamendmentseconds, vamendmenttext
# vproceedings, vmajorityreq, vstatistics, vquorum, vmindiscuss,
# vballot, vforum, voutcome
<vtimeline />
<table class="vote">
<tr>
<th>Proposition et amendement :</th>
<td>samedi 16 novembre 2019</td>
<td></td>
</tr>
<tr>
<th>Période de débat :</th>
<td>vendredi 22 novembre 2019</td>
<td></td>
</tr>
<tr>
<th>Période de scrutin :</th>
<td>samedi 7 décembre 2019 00:00:00 UTC</td>
<td>Vendredi 27 décembre 2019 23:59:59 UTC</td>
</tr>
</table>
Le Responsable du projet a modifié la durée de discussion si bien que la période
minimale de discussion s'achèvera le 30 novembre. [<a
href='https://lists.debian.org/debian-vote/2019/11/msg00189.html'>message</a>]
<vproposerf />
<p>Martin Michlmayr [<email tbm@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00330.html'>texte de la proposition</a>]
</p>
<vsecondsf />
<ol>
<li>Michael Biebl [<email biebl@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00331.html'>message</a>] </li>
<li>Ansgar Burchardt [<email ansgar@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00332.html'>message</a>] </li>
<li>Julien Cristau [<email jcristau@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00333.html'>message</a>] </li>
<li>Enrico Zini [<email enrico@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00334.html'>message</a>] </li>
<li>Matthias Klumpp [<email mak@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00335.html'>message</a>] </li>
<li>Ana Beatriz Guerrero López [<email ana@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00337.html'>message</a>] </li>
<li>Russ Allbery [<email rra@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00338.html'>message</a>] </li>
<li>Intrigeri [<email intrigeri@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00341.html'>message</a>] </li>
<li>Luca Filipozzi [<email lfilipoz@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00343.html'>message</a>] </li>
<li>Moritz Mühlenhoff [<email jmm@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00346.html'>message</a>] </li>
<li>Paul Tagliamonte [<email paultag@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00347.html'>message</a>] </li>
<li>Jordi Mallach [<email jordi@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00348.html'>message</a>] </li>
<li>Philipp Kern [<email pkern@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00350.html'>message</a>] </li>
<li>Holger Levsen [<email holger@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00351.html'>message</a>] </li>
<li>Jeremy Bicha [<email jbicha@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00000.html'>mmessage</a>] </li>
</ol>
<vtextf />
<h3>Choix 1 : priorité à systemd</h3>
<p>Cette résolution est une déclaration de position, selon le paragraphe
section 4.1 (5) de la constitution de Debian :</p>
<p>Les normes et la coopération entre les distributions sont des
facteurs importants dans le choix des technologies principales de
Debian. Il est important de reconnaître que l'écosystème Linux a
largement adopté systemd et que le niveau d'intégration des technologies
de systemd dans les systèmes Linux va croître avec le temps.
</p>
<p>Debian est fière de prendre en charge et d'intégrer de nombreuses
technologies différentes. Dans chacune de nos actions, les coûts et les
bénéfices doivent être examinés à la fois en ce qui concerne les
utilisateurs et du point de vue des effets sur la communauté des
développeurs. Un système de démarrage n'est pas un composant isolé, mais
est profondément intégré au niveau central du système et affecte de
nombreux paquets. Nous croyons que les bénéfices de la prise en charge
de plusieurs systèmes de démarrages ne l'emportent pas sur ses coûts.
</p>
<p>Debian peut continuer à fournir et explorer d'autres systèmes de
démarrage, mais systemd est le seul système de démarrage officiellement
pris en charge. Des rapports de bogue de sévérité “wishlist”
avec des correctifs peuvent être soumis et devront être revus par les
responsables de paquet comme les autres rapports de bogue avec
correctifs. Comme avec systemd, le travail devrait être mené avec
l'amont et en coopération avec les autres distributions Linux et du
logiciel libre lorsque cela est possible. L'accent est mis sur la
standardisation sans dépendance à des niveaux de compatibilité
compliqués.
</p>
<p>Une intégration plus profonde dans Debian mènera à un système plus
intégré et testé, améliorera la standardisation des systèmes Linux, et
apportera de nombreuses nouvelles technologies à nos utilisateurs. Les
paquets peuvent se fonder sur les fonctionnalités fournies par systemd,
et sont encouragés à en utiliser toutes les possibilités. Les solutions
basées sur les technologies de systemd permettront plus de coopération
entre les distributions. Le projet travaillera à des propositions et
coordonnera des transitions à partir des solutions spécifiques à Debian
le cas échéant.
</p>
<vproposerb />
<p>Sam Hartman [<email hartmans@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00117.html'>texte de la proposition</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00293.html'>amendement</a>]
</p>
<vsecondsb />
Cet amendement a été soumis par le Responsable actuel du projet et n’a donc pas besoin d’être soutenu.
# <ol>
# </ol>
<vtextb />
<h3>Choix 2 : systemd mais nous encourageons l’exploration des alternatives</h3>
<p>Grâce à ses pouvoirs conférés par la section 4.1 (5) de la Constitution,
le projet fait la déclaration suivante décrivant notre position actuelle
sur les systèmes de démarrage, leur pluralité et l’utilisation des outils
de systemd. Cette déclaration décrit la position du projet au moment de son
adoption. Cette position peut évoluer avec le temps sans nécessiter le recours
à des résolutions générales futures. Le processus de résolution générale reste
disponible si le projet a besoin d’une décision et ne peut parvenir à un
consensus.
</p>
<p>Le projet Debian reconnaît que les unités de service (<q>service units</q>)
de systemd sont la configuration privilégiée pour décrire comment démarrer
un démon ou un service. Cependant, Debian reste un environnement où les
développeurs et les utilisateurs peuvent explorer et développer des systèmes
de démarrage alternatifs et des alternatives aux fonctionnalités de systemd.
Les personnes intéressées par l’exploration de ces alternatives doivent
fournir les ressources en développement et empaquetage nécessaires pour
réaliser ce travail. Les technologies telles qu’elogind qui facilitent
l’exploration d’alternatives tout en exécutant du logiciel dépendant de
certaines interfaces de systemd restent importantes pour Debian. Il est
important que le projet soutienne les efforts des développeurs travaillant
sur ces technologies pour lesquelles un chevauchement avec le reste du
projet existe, en évaluant par exemple les modifications et en participant
aux discussions dans un délai convenable.
</p>
<p>Les paquets devraient inclure des unités de service ou des scripts de
démarrage pour lancer les démons et les services. Les paquets peuvent utiliser
toutes les fonctionnalités de systemd à la discrétion du responsable du
paquet, à condition que cela soit cohérent avec les autres
prérequis de la charte et l’attente que les paquets ne devraient pas dépendre
de fonctionnalités expérimentales ou non prises en charge (par Debian) venant
d’autres paquets. Les paquets peuvent inclure la prise en charge de systèmes
de démarrage alternatifs en plus de systemd et peuvent inclure des
alternatives pour toutes les interfaces spécifiques à systemd qu’ils utilisent.
Les responsables utilisent leurs procédures normales pour décider des
modifications à inclure.
</p>
<p>Debian s’engage à travailler avec les distributions dérivées qui font des
choix différents à propos des systèmes de démarrage. De même que pour toutes
nos interactions avec l’aval, les responsables concernés travailleront avec
les responsables en aval pour déterminer quelles modifications ont leur place
dans Debian et lesquelles restent dans les distributions dérivées.
</p>
<vproposera />
<p>Sam Hartman [<email hartmans@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00257.html'>texte de la proposition</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00258.html'>amendement</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00260.html'>amendement</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00293.html'>amendement</a>]
</p>
<vsecondsa />
Cet amendement a été soumis par le Responsable actuel du projet et n’a donc pas besoin d’être soutenu.
# <ol>
# </ol>
<vtexta />
<h3>Choix 3 : la prise en charge de plusieurs systèmes de démarrage est importante</h3>
<p>Le projet fait la déclaration suivante décrivant notre position actuelle
sur les systèmes de démarrage, leur pluralité et l’utilisation des outils
de systemd. Cette déclaration décrit la position du projet au moment de son
adoption. Cette position peut évoluer avec le temps sans nécessiter le recours
à des résolutions générales futures. Le processus de résolution générale reste
disponible si le projet a besoin d’une décision et ne peut parvenir à un
consensus.
</p>
<p>Le projet continue d’accorder de l’importance au fait de pouvoir exécuter
des systèmes Debian avec d’autres systèmes de démarrage que systemd. Chaque
paquet devrait fonctionner avec un pid1 différent de systemd, à moins qu'il
n'ait été conçu par l'amont pour fonctionner exclusivement avec systemd et
qu'aucune prise en charge pour son exécution sans systemd ne soit disponible.
C'est un bogue important (même si ce n'est pas un bogue sérieux) quand des
paquets devraient fonctionner sans systemd, mais ne le font pas. Selon les
lignes de conduites NMU, les développeurs peuvent appliquer des
<q>non-maintener upload</q> pour corriger ces bogues.
</p>
<p>Un logiciel ne doit pas être considéré comme étant conçu par l'amont
pour fonctionner exclusivement avec systemd, simplement parce que l'amont ne
fournit pas ou n'acceptera pas un script de démarrage.
</p>
<p>La modification de la charte pour adopter les fonctionnalités de systemd
à la place d’approches existantes est déconseillée, sauf si une
implémentation équivalente de cette fonctionnalité est disponible dans les
autres systèmes de démarrage.
</p>.
<vproposerd />
<p>Ian Jackson [<email iwj@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00163.html'>texte de la proposition</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00206.html'>texte d'amendement</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00283.html'>texte d'amendement</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00306.html'>texte d'amendement</a>]
</p>
<vsecondsd />
<ol>
<li>Russ Allbery [<email rra@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00128.html'>message</a>] </li>
<li>Sean Whitton [<email spwhitton@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00133.html'>message</a>] </li>
<li>Simon Richter [<email sjr@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00138.html'>message</a>] </li>
<li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00140.html'>message</a>] </li>
<li>Dmitry Bogatov [<email kaction@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00156.html'>message</a>] </li>
<li>Jonathan McDowell [<email noodles@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00168.html'>message</a>] </li>
<li>Matthew Vernon [<email matthew@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00174.html'>message</a>] </li>
<li>James Clarke [<email jrtc27@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00205.html'>message</a>] </li>
<li>Thomas Goirand [<email zigo@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00247.html'>message</a>] </li>
<li>Jonathan Dowland [<email jmtd@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00289.html'>message</a>] </li>
</ol>
<vtextd />
<h3>Choix 4 : prise en charge des systèmes non systemd, sans bloquer l'évolution</h3>
<h4>PRINCIPES</h4>
<p>1. Nous souhaitons continuer à prendre en charge plusieurs systèmes de
démarrage dans un avenir proche. Et nous voulons améliorer la prise en
charge de systemd.
</p>
<p>2. Il appartient essentiellement aux communautés dans chaque écosystème
logiciel d'entretenir et de développer ses programmes respectifs – mais
avec le soutien actif des autres responsables et contrôleurs lorsque
cela s'avère nécessaire.
</p>
<h4>DÉPENDANCES DE SYSTEMD</h4>
<p>3. Dans l'idéal, les paquets devraient être pleinement fonctionnels
avec tous les systèmes de démarrage. Cela signifie (par exemple) que les
démons devraient fournir des scripts de démarrage traditionnels ou utiliser
d'autres mécanismes pour assurer qu'ils sont démarrés, sans systemd.
Cela signifie aussi que les logiciels de bureau devraient être
installables, et idéalement pleinement fonctionnels sans systemd.
</p>
<p>4. Aussi échouer à prendre en charge des systèmes non systemd,
lorsque cette prise en charge n'existe pas, est un bogue. Mais ce
n'est <b>pas</b> un bogue critique pour la publication. Il appartient au
responsable de paquet de déterminer si la nécessité de systemd est
enregistrée comme un bogue officiel dans le système de bogue de Debian,
lorsqu'il n'y a pas de correctif disponible.
</p>
<p>5. Lorsqu'un paquet voit ses fonctionnalités réduites en l'absence de
systemd, cela ne devrait pas en général être en utilisant une dépendance
(<q>Depends</q>) ou une recommandation (<q>Recommends</q>) de systemd-sysv
(de façon directe ou indirecte). Cela parce que avec une telle dépendance,
l'installation de ce type de paquet peut tenter de changer de système de
démarrage, ce qui n'est pas ce que souhaite l'utilisateur. Par exemple, un
démon possédant seulement un script de fichier d'unité de systemd devrait
encore être installable sur un système non systemd, dans la mesure où il
pourrait être lancé manuellement.
</p>
<p>Une des conséquences de cela est que sur les systèmes non systemd, il
est possible d'installer un logiciel qui ne fonctionne pas, ou qui ne
fonctionne pas correctement, à cause d'une dépendance non déclarée à
systemd. C'est regrettable, mais essayer de changer le système de démarrage de
l'utilisateur est pire. Nous espérons que de meilleures approches
techniques pourront être développées pour corriger cela.
</p>
<p>6. Nous reconnaissons que certains responsables de paquet considèrent
les scripts de démarrage comme un fardeau et nous espérons que la communauté
pourra trouver des solutions pour faciliter l'ajout de la
prise en charge de systèmes de démarrage différents de celui par défaut. Des
discussions sur la conception de tels systèmes devraient être amicales
et concertées, et si des arrangements appropriés sont développés, ils
devraient bénéficier de la prise en charge habituelle dans Debian.
</p>
<h4>LES CONTRIBUTIONS DE PRISE EN CHARGE NON SYSTEMD SERONT ACCEPTÉES</h4>
<p>7. L'échec de la prise en charge de systèmes non systemd alors que
cette prise en charge est disponible ou offerte sous la forme de
correctifs (ou de paquets), <b>devrait</b> être traité comme un bogue
critique pour la publication. Par exemple, les scripts de démarrage <b>ne
doivent</b> pas être supprimés simplement parce qu'une unité de systemd est
fournie à la place ; les correctifs qui contribuent à la prise en charge
d'autres systèmes de démarrage (sans effet important sur les installations de
systemd) devraient être classés comme des bogues de sévérité
“serious”.
</p>
<p>Cela est destiné à fournir un moyen léger mais efficace pour assurer
qu'une prise en charge satisfaisante peut être fournie aux
utilisateurs de Debian même quand les priorités du responsable du
paquet sont ailleurs. (Faire appel au comité technique pour des
correctifs individuels n'est pas raisonnable.)
</p>
<p>Si les correctifs contiennent aussi un bogue critique pour la
publication (initialement selon l'avis du responsable du paquet, et
en fin compte de celui de l'équipe de publication) alors, bien sûr, le
rapport de bogue pourra être déclassé ou fermé.
</p>
<p>8. Les responsables des composants de systemd, ou d'autres contrôleurs
(y compris d'autres responsables ou l'équipe de publication) ont
parfois à évaluer les contributions techniques visant à prendre en
charge les utilisateurs d'autres systèmes que systemd.
L'acceptabilité, pour les utilisateurs de systèmes de démarrage autres
que celui par défaut, des risques de défaillance est un sujet qui importe
aux responsables de ces systèmes et de la communauté avoisinante. Mais ces
contributions ne devraient pas exposer à des risques non négligeables
les utilisateurs de la configuration par défaut (systemd avec les
paquets recommandés installés).
</p>
<h4>OUTILS DÉCLARATIFS DE SYSTEMD NON LIÉS AU DÉMARRAGE</h4>
<p>9. Systemd fournit une diversité d'outils en plus du lancement de
démons. Par exemple, la création d'utilisateurs système ou de
répertoires temporaires. L'approche actuelle de Debian est souvent
basée sur des scripts de debhelper.
</p>
<p>
En général des approches plus déclaratives sont meilleures. Lorsque :</p>
<ul>
<li>systemd fournit un outil de ce type,
<li>il existe une spécification de l'outil (ou d'un sous-ensemble
adapté),
<li>l'outil est meilleur que d'autres approches disponibles
dans Debian, par exemple en étant plus déclaratif,
<li>il est acceptable de demander aux développeurs de systèmes non
systemd, y compris non Linux, de l'implémenter,
<li>y compris en tenant compte de la quantité du travail impliquée,
</ul>
<p>l'outil devrait être documenté dans la charte Debian (par un texte
incorporé et non par une référence à un document externe). La
transition devrait se faire sans problème pour tous les utilisateurs.
La communauté non systemd devrait se voir accorder au moins six mois,
douze mois si possible, pour développer son implémentation. (Il en va
de même pour toute amélioration future.)
</p>
<p>
Si un consensus politique ne peut être atteint sur un outil, le comité
technique, pourrait prendre une décision en se basant sur les souhaits
du projet tels qu'exprimés dans cette résolution générale.
</p>
<h4>ÊTRE CONCILIANTS LES UNS AVEC LES AUTRES</h4>
<p>10. En général, les responsables de logiciels concurrents, y compris
les responsables des divers systèmes de démarrage concurrents, devraient être
conciliants sur les besoins de chacun des autres systèmes. Cela comprend
les besoins et le confort des utilisateurs des configurations
raisonnables autres que celle par défaut.
</p>
<p>11. Les commentaires généraux négatifs sur les logiciels et leur
communauté, y compris aussi bien sur systemd lui-même que sur les
systèmes de démarrage non systemd, sont fortement déconseillés. Ni les
messages exprimant une aversion globale envers systemd ou ceux
prédisant la disparition des systèmes non systemd n'ont leur place
dans les forums de communication de Debian, de même que les références à
des bogues qui n'ont pas de pertinence par rapport au sujet en cours.
</p>
<p>Les communications sur les forums Debian sur ces sujets devront toutes
être stimulantes et conviviales, même lorsqu'il s'agit de discussions
sur des problèmes techniques. Nous demandons que tous les responsables
de forum de communication appliquent strictement ce principe.
</p>
<p>12. Nous demandons respectueusement à tous les contributeurs de
Debian, y compris les responsables de paquets, les éditeurs de la
charte Debian, l'équipe de publication, le comité technique et le
chef du projet Debian, de suivre ces objectifs et ces principes dans
leur travail et de les intégrer dans leurs documents, etc., d'une
manière appropriée. (Cette résolution est une déclaration de position,
paragraphe section 4.1 (5).)
</p>
<vproposerh />
<p>Ian Jackson [<email iwj@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00142.html'>texte la proposition</a>]
</p>
<vsecondsh />
<ol>
<li>Jonas Smedegaard [<email js@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00129.html'>message</a>] </li>
<li>Holger Levsen [<email holger@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00131.html'>message</a>] </li>
<li>Michael Lustfield [<email mtecknology@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00132.html'>message</a>] </li>
<li>Guilhem Moulin [<email guilhem@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00134.html'>message</a>] </li>
<li>Matthew Vernon [<email matthew@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00137.html'>message</a>] </li>
<li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00139.html'>message</a>] </li>
<li>gregor herrmann [<email gregoa@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00156.html'>message</a>] </li>
<li>Sean Whitton [<email spwhitton@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00163.html'>message</a>] </li>
</ol>
<vtexth />
<h3>Choix 5 : Prendre en charge la portabilité sans bloquer les progrès</h3>
<h4>PRINCIPES</h4>
<p>1. Le projet Debian réaffirme son engagement à être la colle qui relie
et intègre différents logiciels qui fournissent des fonctionnalités
similaires ou équivalentes à leurs divers utilisateurs qu'ils soient
humains ou d'autres logiciels, ce qui est un des traits principaux
définissant une distribution.
</p>
<p>2. Nous considérons que la portabilité de différentes plateformes
matérielles et piles logicielles est un aspect important du travail que
nous menons comme distribution, ce qui rend meilleurs les logiciels
d'un point de vue architectural, plus robustes et plus évolutifs.
</p>
<p>3. Nous reconnaissons que différents projets amont ont des vues
différentes sur le développement logiciel, les cas d'utilisation, la
portabilité et la technologie en général. Nous reconnaissons également
que les utilisateurs de ces projets évaluent différemment les
concessions et ont en même temps des exigences diverses et valables et
des besoins satisfaits par ces diverses vues.
</p>
<p>4. Suivant notre tradition, nous accepterons l'intégration de
ces diverses technologies qui pourraient avoir parfois des visions
divergentes, pour leur permettre de coexister en harmonie dans notre
distribution, en réconciliant ces conflits grâce à des moyens
techniques, aussi longtemps qu'il y aura des gens souhaitant fournir
un effort.
</p>
<p>5. Cela nous permet de continuer à offrir un large éventail d'usages de
notre distribution (dont certains pourraient ne pas même avoir été
envisagés par nous). Ces usages vont des serveurs aux ordinateurs de
bureau ou extrêmement embarqués ; cela va d'usages généralistes à des
usages très spécifiques taillés sur mesure ; que ces projets soient liés
au matériel ou basés sur des logiciels, des bibliothèques, des démons,
des environnements de bureau complets ou d'autres parties de la pile
logicielle.
</p>
<h4>DÉPENDANCES DE SYSTEMD</h4>
<p>6. Dans l'idéal, les paquets devraient être pleinement fonctionnels
avec tous les systèmes de démarrage. Cela signifie (par exemple) que les
démons devraient fournir des scripts de démarrage traditionnels ou utiliser
d'autres mécanismes pour assurer qu'ils sont démarrés, sans systemd.
Cela signifie aussi que les logiciels de bureau devraient être
installables, et idéalement pleinement fonctionnels sans systemd.
</p>
<p>7. Aussi échouer à prendre en charge des systèmes non systemd,
lorsque cette prise en charge n'existe pas, est un bogue. Mais ce
n'est <b>pas</b> un bogue critique pour la publication. Il appartient au
responsable de paquet de déterminer si la nécessité de systemd est
enregistrée comme un bogue officiel dans le système de bogue de Debian,
lorsqu'il n'y a pas de correctif disponible.
</p>
<p>8. Lorsqu'un paquet voit ses fonctionnalités réduites en l'absence de
systemd, cela ne devrait pas en général être en utilisant une dépendance
(<q>Depends</q>) ou une recommandation (<q>Recommends</q>) de systemd-sysv
(de façon directe ou indirecte). Cela parce que avec une telle dépendance,
l'installation de ce type de paquet peut tenter de changer de système de
démarrage, ce qui n'est pas ce que souhaite l'utilisateur. Par exemple, un
démon possédant seulement un script de fichier d'unité de systemd devrait
encore être installable sur un système non systemd, dans la mesure où il
pourrait être lancé manuellement.
</p>
<p>Une des conséquences de cela est que sur les systèmes non systemd, il
est possible d'installer un logiciel qui ne fonctionne pas, ou qui ne
fonctionne pas correctement, à cause d'une dépendance non déclarée à
systemd. C'est regrettable, mais essayer de changer le système de démarrage de
l'utilisateur est pire. Nous espérons que de meilleures approches
techniques pourront être développées pour corriger cela.
</p>
<p>9. Nous reconnaissons que certains responsables de paquet considèrent
les scripts de démarrage comme un fardeau et nous espérons que la communauté
pourra trouver des solutions pour faciliter l'ajout de la
prise en charge de systèmes de démarrage différents de celui par défaut. Des
discussions sur la conception de tels systèmes devraient être amicales
et concertées, et si des arrangements appropriés sont développés, ils
devraient bénéficier de la prise en charge habituelle dans Debian.
</p>
<h4>LES CONTRIBUTIONS DE PRISE EN CHARGE NON SYSTEMD SERONT ACCEPTÉES</h4>
<p>10. L'échec de la prise en charge de systèmes non systemd alors que
cette prise en charge est disponible ou offerte sous la forme de
correctifs (ou de paquets), <b>devrait</b> être traité comme un bogue
critique pour la publication. Par exemple, les scripts de démarrage <b>ne
doivent</b> pas être supprimés simplement parce qu'une unité de systemd est
fournie à la place ; les correctifs qui contribuent à la prise en charge
d'autres systèmes de démarrage (sans effet important sur les installations de
systemd) devraient être classés comme des bogues de sévérité
“serious”.
</p>
<p>Cela est destiné à fournir un moyen léger mais efficace pour assurer
qu'une prise en charge satisfaisante peut être fournie aux
utilisateurs de Debian même quand les priorités du responsable du
paquet sont ailleurs. (Faire appel au comité technique pour des
correctifs individuels n'est pas raisonnable.)
</p>
<p>Si les correctifs contiennent aussi un bogue critique pour la
publication (initialement selon l'avis du responsable du paquet, et
en fin compte de celui de l'équipe de publication) alors, bien sûr, le
rapport de bogue pourra être déclassé ou fermé.
</p>
<p>11. Les responsables des composants de systemd, ou d'autres contrôleurs
(y compris d'autres responsables ou l'équipe de publication) ont
parfois à évaluer les contributions techniques visant à prendre en
charge les utilisateurs d'autres systèmes que systemd.
L'acceptabilité, pour les utilisateurs de systèmes de démarrage autres
que celui par défaut, des risques de défaillance est un sujet qui importe
aux responsables de ces systèmes et de la communauté avoisinante. Mais ces
contributions ne devraient pas exposer à des risques non négligeables
les utilisateurs de la configuration par défaut (systemd avec les
paquets recommandés installés).
</p>
<h4>OUTILS DÉCLARATIFS DE SYSTEMD NON LIÉS AU DÉMARRAGE</h4>
<p>12. Systemd fournit une diversité d'outils en plus du lancement de
démons. Par exemple, la création d'utilisateurs système ou de
répertoires temporaires. L'approche actuelle de Debian est souvent
basée sur des scripts de debhelper.
</p>
<p>
En général des approches plus déclaratives sont meilleures. Lorsque :</p>
<ul>
<li>systemd fournit un outil de ce type,
<li>il existe une spécification de l'outil (ou d'un sous-ensemble
adapté),
<li>l'outil est meilleur que d'autres approches disponibles
dans Debian, par exemple en étant plus déclaratif,
<li>il est acceptable de demander aux développeurs de systèmes non
systemd, y compris non Linux, de l'implémenter,
<li>y compris en tenant compte de la quantité du travail impliquée,
</ul>
<p>l'outil devrait être documenté dans la charte Debian (par un texte
incorporé et non par une référence à un document externe). La
transition devrait se faire sans problème pour tous les utilisateurs.
La communauté non systemd devrait se voir accorder au moins six mois,
douze mois si possible, pour développer son implémentation. (Il en va
de même pour toute amélioration future.)
</p>
<p>
Si un consensus politique ne peut être atteint sur un outil, le comité
technique, pourrait prendre une décision en se basant sur les souhaits
du projet tels qu'exprimés dans cette résolution générale.
</p>
<h4>ÊTRE CONCILIANTS LES UNS AVEC LES AUTRES</h4>
<p>13. En général, les responsables de logiciels concurrents, y compris
les responsables des divers systèmes de démarrage concurrents, devraient être
conciliants sur les besoins de chacun des autres systèmes. Cela comprend
les besoins et le confort des utilisateurs des configurations
raisonnables autres que celle par défaut.
</p>
<p>14. Les commentaires généraux négatifs sur les logiciels et leur
communauté, y compris aussi bien sur systemd lui-même que sur les
systèmes de démarrage non systemd, sont fortement déconseillés. Ni les
messages exprimant une aversion globale envers systemd ou ceux
prédisant la disparition des systèmes non systemd n'ont leur place
dans les forums de communication de Debian, de même que les références à
des bogues qui n'ont pas de pertinence par rapport au sujet en cours.
</p>
<p>Les communications sur les forums Debian sur ces sujets devront toutes
être stimulantes et conviviales, même lorsqu'il s'agit de discussions
sur des problèmes techniques. Nous demandons que tous les responsables
de forum de communication appliquent strictement ce principe.
</p>
<p>15. Nous demandons respectueusement à tous les contributeurs de
Debian, y compris les responsables de paquets, les éditeurs de la
charte Debian, l'équipe de publication, le comité technique et le
chef du projet Debian, de suivre ces objectifs et ces principes dans
leur travail et de les intégrer dans leurs documents, etc., d'une
manière appropriée. (Cette résolution est une déclaration de position,
paragraphe section 4.1 (5).)
</p>
<vproposere />
<p>Dmitry Bogatov [<email kaction@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00202.html'>texte de la dernière proposition</a>]
</p>
<vsecondse />
<ol>
<li>Ian Jackson [<email iwj@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00193.html'>message</a>] </li>
<li>Matthew Vernon [<email matthew@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00194.html'>message</a>] </li>
<li>Jonathan Carter [<email jcc@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00195.html'>message</a>] </li>
<li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00196.html'>message</a>] </li>
<li>Axel Beckert [<email abe@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00197.html'>message</a>] </li>
<li>Brian Gupta [<email bgupta@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00234.html'>message</a>] </li>
<li>Simon Richter [<email sjr@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00238.html'>message</a>] </li>
</ol>
<vtexte />
<h3>Choix 6 : la prise en charge de plusieurs systèmes de démarrage est requise</h3>
<p>Pouvoir exécuter des systèmes Debian avec des systèmes de démarrage
différents de systemd continue à être utile au projet. Chaque paquet DOIT
fonctionner avec un pid1 différent de systemd, à moins qu'il n'ait été conçu
par l'amont pour fonctionner exclusivement avec systemd et qu'aucune prise en
charge pour son exécution sans systemd ne soit disponible.
</p>
<p>Un logiciel ne doit pas être considéré comme étant conçu par l'amont
pour fonctionner exclusivement avec systemd, simplement parce que l'amont ne
fournit pas ou n'acceptera pas un script de démarrage.
</p>
<vproposerg />
<p> Guillem Jover [<email guillem@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00361.html'>texte de la proposition</a>]
</p>
<vsecondsg />
<ol>
<li>Simon Richter [<email sjr@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00362.html'>message</a>] </li>
<li>gregor herrmann [<email gregoa@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00363.html'>message</a>] </li>
<li>Jonas Smedegaard [<email js@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00364.html'>message</a>] </li>
<li>Guilhem Moulin [<email guilhem@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00365.html'>message</a>] </li>
<li>Ricardo Mones [<email mones@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00366.html'>message</a>] </li>
<li>Mathias Behrle [<email mbehrle@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00367.html'>message</a>] </li>
<li>Steve Kostecke [<email steve@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00368.html'>message</a>] </li>
<li>Alberto Gonzalez Iniesta [<email agi@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00375.html'>message</a>] </li>
</ol>
<vtextg />
<h3>Choix 7 : prise en charge de la portabilité et de multiples implémentations</h3>
<h4>Titre : réaffirmer notre engagement à prendre en charge la portabilité et de multiples implémentations</h4>
<p>Le projet Debian réaffirme son engagement à être la colle qui relie
et intègre différents logiciels qui fournissent des fonctionnalités
similaires ou équivalentes à leurs divers utilisateurs qu'ils soient
humains ou d'autres logiciels, ce qui est un des traits principaux
définissant une distribution.
</p>
<p>Nous considérons que la portabilité de différentes plateformes
matérielles et piles logicielles est un aspect important du travail que
nous menons comme distribution, ce qui rend meilleurs les logiciels
d'un point de vue architectural, plus robustes et plus évolutifs.
</p>
<p>Nous reconnaissons que différents projets amont ont des vues
différentes sur le développement logiciel, les cas d'utilisation, la
portabilité et la technologie en général. Nous reconnaissons également
que les utilisateurs de ces projets évaluent différemment les
concessions et ont en même temps des exigences diverses et valables et
des besoins satisfaits par ces diverses vues.
</p>
<p>Suivant notre tradition, nous accepterons l'intégration de
ces diverses technologies qui pourraient avoir parfois des visions
divergentes, pour leur permettre de coexister en harmonie dans notre
distribution, en réconciliant ces conflits grâce à des moyens
techniques, aussi longtemps qu'il y aura des gens souhaitant fournir
un effort.
</p>
<p>Cela nous permet de continuer à offrir un large éventail d'usages de
notre distribution (dont certains pourraient ne pas même avoir été
envisagés par nous). Ces usages vont des serveurs aux ordinateurs de
bureau ou extrêmement embarqués ; cela va d'usages généralistes à des
usages très spécifiques taillés sur mesure ; que ces projets soient liés
au matériel ou basés sur des logiciels, des bibliothèques, des démons,
des environnements de bureau complets ou d'autres parties de la pile
logicielle.
</p>
<vproposerc />
<p>Sam Hartman [<email hartmans@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00117.html'>texte de la proposition</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00293.html'>amendement</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00381.html'>retrait</a>]
</p>
<vsecondsc />
Cet amendement a été soumis par le Responsable actuel du projet et n’a donc pas besoin d’être soutenu.
<ol>
<li>Ansgar Burchardt [<email ansgar@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00253.html'>message</a>] </li>
</ol>
<vtextc />
<h3>Priorité à systemd comme système de démarrage et autres outils (retiré)</h3>
# <vquorum />
# <p>
# Avec la liste actuelle des <a href="vote_002_quorum.log">développeurs
# ayant voté</a>, nous avons :
# </p>
# <pre>
##include 'vote_002_quorum.txt'
# </pre>
##include 'vote_002_quorum.src'
#
# <vstatistics />
# <p>
# Pour cette résolution générale, comme d'habitude,
## <a href="https://vote.debian.org/~secretary/gr_private/";>des statistiques</a>
# des <a href="suppl_002_stats">statistiques</a>
# sur les bulletins et les accusés de réception sont rassemblées
# périodiquement durant la période du scrutin.
## De plus, la liste des votants
## sera enregistrée. La feuille d'émargement
## sera également disponible.
# De plus, la liste des <a href="vote_002_voters.txt">votants</a>
# sera enregistrée. La <a href="vote_002_tally.txt">feuille
# de compte</a> pourra être aussi consultée.
# </p>
# <vmajorityreq />
# <p>
# La proposition a besoin d’une majorité simple.
# </p>
##include 'vote_002_majority.src'
# <voutcome />
##include 'vote_002_results.src'
<hrline />
<address>
<a href="mailto:secretary@debian.org";>Secrétaire du projet Debian</a>
</address>