(fr) vote_002.wml, initial and partial translation

1 files changed, 417 insertions, 0 deletions

diff --git a/french/vote/2019/vote_002.wml b/french/vote/2019/vote_002.wml
new file mode 100644
index 00000000000..0d7af681c18
--- /dev/null
+++ b/french/vote/2019/vote_002.wml
@@ -0,0 +1,417 @@
+#use wml::debian::translation-check translation="6e99d5f8ddd2bd3951421c72a1c6fe7c8be29f58" maintainer="Jean-Pierre Giraud"
+<define-tag pagetitle>General Resolution: Init Systems and systemd</define-tag>
+<define-tag status>P</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>Proposal and amendment</th>
+        <td>2019-11-16</td>
+		<td></td>
+      </tr>
+      <tr>
+        <th>Discussion Period:</th>
+		<td>2019-11-19</td>
+		<td></td>
+      </tr>
+      <tr>
+        <th>Voting Period:</th>
+            <td></td>
+            <td></td>
+      </tr>
+    </table>
+
+    <vproposera />
+    <p>Sam Hartman [<email hartmans@debian.org>]
+	[<a href='https://lists.debian.org/debian-vote/2019/11/msg00117.html'>text of proposal</a>]
+    </p>
+
+    <vsecondsa />
+	This amendment has been submitted by the current Project Leader, and thus does not require seconding
+#    <ol>
+#    </ol>
+    <vtexta />
+	<h3>Choice 1: Affirm Init Diversity</h3>
+
+<p>Using its power under Constitution section 4.1 (5), the project issues
+the following statement describing our current position on Init
+systems, Init system diversity, and the use of systemd facilities.  This
+statement describes the position of the project at the time it is
+adopted.  That position may evolve as time passes without the need to
+resort to future general resolutions.  The GR process remains
+available if the project needs a decision and cannot come to a
+consensus.
+
+<p>Being able to run Debian systems with init systems other than systemd
+continues to be something that the project values.  With one
+exception, the Debian Project affirms the current policy on init
+scripts and starting daemons (policy 9.3.2, 9.11).  Roughly, packages
+should include init scripts to start services that are included.
+Policy notes that early boot services like those started from
+/etc/rcS.d may be tied closely to the init system in use and thus may need to be
+handled differently for each init system.  Init
+scripts are the lowest common denominator across all init systems.
+Packages may include support for init systems like systemd service
+units in addition to init scripts.  Current policy makes it an RC bug
+to include a service unit without an init script.
+
+<p>Policy editors are requested to amend policy; a package having a
+service unit but without an init script is no longer an RC bug, but
+including an init script is appropriate for a non-maintainer upload.
+Policy editors are requested to consider whether there are cases where
+removing an init script that used to be provided should be RC because
+it would break a system on upgrade.
+
+<p>Once the community of users of an alternate init system have said that
+a solution is sufficiently functional for them, others should not
+generally second guess this determination.
+
+<p>systemd unit files included in the package may use any systemd feature
+or service at the package maintainer's discretion, provided that this
+is consistent with other Policy requirements and the normal
+expectation that packages shouldn't depend on experimental or
+unsupported (in Debian) features of other packages.
+
+<p>Init scripts must use only facilities common to all supported init
+systems in Debian and therefore may not use services that depend on
+systemd.
+
+<p>Similarly, packages may freely use other systemd facilities such as
+timer units, subject to the above constraints, but not also supporting
+non-systemd systems is a (non-RC) bug and non-maintainer uploads to add
+that support are appropriate.
+
+<p>systemd facilities may be used at the discretion of package
+maintainers, but modification of Policy to adopt systemd facilities
+instead of existing approaches is discouraged unless an equivalent
+implementation of that facility is available for other init systems.
+
+    <vproposerb />
+    <p>Sam Hartman [<email hartmans@debian.org>]
+	[<a href='https://lists.debian.org/debian-vote/2019/11/msg00117.html'>text of proposal</a>]
+    </p>
+    <vsecondsb />
+	This amendment has been submitted by the current Project Leader, and thus does not require seconding
+#    <ol>
+#    </ol>
+    <vtextb />
+	<h3>Choice 2: systemd but we Support Exploring Alternatives</h3>
+
+<p>Using its power under Constitution section 4.1 (5), the project issues
+the following statement describing our current position on Init
+systems, Init system diversity, and the use of systemd facilities.  This
+statement describes the position of the project at the time it is
+adopted.  That position may evolve as time passes without the need to
+resort to future general resolutions.  The GR process remains
+available if the project needs a decision and cannot come to a
+consensus.
+
+<p>The Debian project recognizes that systemd service units are the
+preferred configuration for describing how to start a daemon/service.
+However, Debian remains an environment where developers and users can
+explore and develop alternate init systems and alternatives to systemd
+features.  Those interested in exploring such alternatives need to
+provide the necessary development and packaging resources to do that
+work.  Technologies such as elogind that facilitate exploring
+alternatives while running software that depends on some systemd
+interfaces remain important to Debian.  It is important that the
+project support the efforts of developers working on such technologies
+where there is overlap between these technologies and the rest of the
+project, for example by reviewing patches and participating in
+discussions in a timely manner.
+
+<p>Packages should include service units or init scripts to start daemons
+and services.  Packages may use any systemd facility at the
+package maintainer's discretion, provided that this is consistent with
+other Policy requirements and the normal expectation that packages
+shouldn't depend on experimental or unsupported (in Debian) features
+of other packages.  Packages may include support for alternate init
+systems besides systemd and may include alternatives for any
+systemd-specific interfaces they use.  Maintainers use their normal
+procedures for deciding which patches to include.
+
+<p>Debian is committed to working with derivatives that make different
+choices about init systems.  As with all our interactions with
+downstreams, the relevant maintainers will work with the downstreams to
+figure out which changes it makes sense to fold into Debian and which
+changes remain purely in the derivative.
+
+    <vproposerc />
+    <p>Sam Hartman [<email hartmans@debian.org>]
+	[<a href='https://lists.debian.org/debian-vote/2019/11/msg00117.html'>text of proposal</a>]
+    </p>
+    <vsecondsc />
+	This amendment has been submitted by the current Project Leader, and thus does not require seconding
+#    <ol>
+#    </ol>
+    <vtextc />
+	<h3>Choice 3: Focus on systemd for Init System and Other Facilities</h3>
+
+<p>Using its power under Constitution section 4.1 (5), the project issues
+the following statement describing our current position on Init
+systems, Init system diversity, and the use of systemd facilities.  This
+statement describes the position of the project at the time it is
+adopted.  That position may evolve as time passes without the need to
+resort to future general resolutions.  The GR process remains
+available if the project needs a decision and cannot come to a
+consensus.
+
+<p>The Debian project recognizes that systemd service units are the
+preferred configuration for describing how to start a daemon/service.
+Packages should include service units or init scripts to start daemons
+and services.  Unless the project or relevant parties have agreed
+otherwise, systemd facilities, where they exist and are stable and
+supported by the systemd maintainers, should be preferred over
+Debian-specific ways of solving the same problem unless the Debian
+approach has clear and obvious advantages.
+
+<p>Providing support for multiple init systems or for alternatives to
+other interfaces provided by systemd is not a project priority at this
+time.
+
+<p>Debian is committed to working with derivatives that make different
+choices about init systems.  As with all our interactions with
+downstreams, the relevant maintainers will work with the downstreams to
+figure out which changes it makes sense to fold into Debian and which
+changes remain purely in the derivative.
+
+<p>Packages may include support for alternate init systems besides
+systemd.  Maintainers use their normal procedures for deciding which
+patches to include.
+
+    <vproposerd />
+    <p>Ian Jackson [<email iwj@debian.org>]
+	[<a href='https://lists.debian.org/debian-vote/2019/11/msg00122.html'>texte de la proposition originale</a>]
+	[<a href='https://lists.debian.org/debian-vote/2019/11/msg00163.html'>texte de la proposition amendée</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>
+    </ol>
+    <vtextd />
+	<h3>Choix 4 : prise en charge des systèmes non systemd, sans bloquer l'évolution</h3>
+
+<h4>Titre : prise en charge des systèmes non systemd, sans bloquer l'évolution</h4>
+
+<h4>PRINCIPES</h4>
+
+<p>1. Nous souhaitons continuer à prendre en charge plusieurs systèmes
+   init dans un avenir proche. Et nous voulons améliorer la prise en
+   charge de systemd. Nous sommes déçu que cela ait nécessité
+   une nouvelle résolution générale.
+
+<p>2. Il appartient essentiellement aux communautés dans chaque écosytème
+   logiciel d'entretenir et de développer ses programmes respectifs
+   – mais avec le soutien actifs des autres mainteneurs et contrôleurs
+   lorsque cela s'avère nécessaire.
+
+<h4>DÉPENDANCES DE SYSTEMD</h4>
+
+<p>3. Dans l'idéal, les paquets devraient être pleinement fonctionnels
+   avec tous les systèmes init. Cela signifie (par exemple) que les
+   démons devraient fournir des scripts init 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>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 *pas* un bogue critique pour la publication. Il appartient au
+   responsable de paquet de déterminer si la nécessité de systemd est
+   enregistré comme un bogue formel dans le système de bogue de Debian,
+   lorsqu'il n'y a pas de correctif disponible.
+
+<p>5. Lorsqu'un paquet voit ses fonctionnalités réduites en absence de
+   systemd, cela ne devrait pas en général être documenté comme paquet
+   dépendant ou recommandé de systemd-sysv (de façon directe ou
+   indirecte. Cela parce que avec cette dépendance, l'installation de ce
+   type de paquet peut tenter de changer de système init, ce qui n'est
+   pas ce que souhaite l'utilisateur. Par exemple, un démon possédant
+   seulement un script de fichier unit de systemd devrait encore être
+   installable sur un système non systemd, dans la mesure où il pourrait
+   être lancé manuellement.
+
+   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 init de
+   l'utilisateur est pire. Nous espérons que de meilleurs approches
+   techniques peuvent être développées pour corriger cela.
+
+<p>6. Nous reconnaissons que certains responsables de paquet considèrent
+   les scripts init comme un fardeau et nous espérons que la communauté
+   est capable de trouver des solutions pour faciliter l'ajout de la
+   prise en charge des systèmes init qui n'est pas 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.
+
+<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), *devrait* être traité comme un bogue
+   critique pour la publication. Par exemple, les scripts init *ne
+   doivent* pas être supprimés parce qu'un unit de systemd est fourni à
+   la place ; les correctifs qui contribuent à la prise en charge
+   d'autres systèmes init (sans effet important sur les installations de
+   systemd) devraient être remplis comme des bogues de sévérité
+   « serious ».
+
+   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.)
+
+   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>8. Les responsables des composants de systemd, ou d'autres contrôleurs
+   (y compris d'autres mainteneurs 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 systèmes init 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é voisine. 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).
+
+<h4>FONCTIONS DÉCLARATIVES DE SYSTEMD NON LIÉES À INIT</h4>
+
+<p>9. systemd fournit une diversité de fonctions 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.
+
+   En général des approches plus déclaratives sont meilleures. Lorsque
+     – systemd fournit une fonction de ce type
+     – il existe une spécification de la fonction (ou sous-ensemble
+       adapté)
+     – la fonction est meilleure que d'autres approches disponibles
+       dans Debian, par exemple en étant plus déclarative
+     – il est acceptable de demander aux développeurs de systèmes non
+       systemd, y compris non Linux, de l'implémenter
+     – y compris en tenant compte de la quantité du travail impliqué
+   la fonction devrait être documenté dans la charge 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
+   même pour toute amélioration future.)
+
+   Si un consensus politique ne peut être cy consensus ne peut être
+   atteint sur une fonction, le comité technique, pourrait prendre une
+   décision en ce basant sur les souhaits du projet tels qu'exprimés dans
+   cette résolution générale.
+
+<h4>ÊTRE PARFAITS 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 init concurrents, devraient être
+   conciliants sur les besoin de chacun des autres système. Cela comprend
+   les besoins et le confort des utilisateurs des configurations
+   raisonnables autre que celle par défaut.
+
+<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 init non systemd, sont fortement déconseillés. Ni les
+   messages exprimant une aversion globale en vers 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 les références à
+   des bogues qui n'ont pas de pertinence par rapport au sujet en cours.
+
+   Les communications sur les forum Debian sur ces sujets devront toutes
+   être stimulantes et plaisantes, même lorsqu'il s'agit de discussion
+   sur des problèmes techniques. Nous demandons que tous les responsables
+   de forum de communication appliquent strictement ce principe.
+
+<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 s4.1(5).)
+  
+
+#    <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>