Résolution générale : les systèmes de démarrage et systemd

Calendrier

Proposition et amendement :	samedi 16 novembre 2019
Période de débat :	vendredi 22 novembre 2019
Période de scrutin :	samedi 7 décembre 2019 00:00:00 UTC	Vendredi 27 décembre 2019 23:59:59 UTC

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. [message]

Déposant de la proposition F

Martin Michlmayr [[email protected]] [texte de la proposition]

Parrains de la proposition F

Michael Biebl [[email protected]] [message]
Ansgar Burchardt [[email protected]] [message]
Julien Cristau [[email protected]] [message]
Enrico Zini [[email protected]] [message]
Matthias Klumpp [[email protected]] [message]
Ana Beatriz Guerrero López [[email protected]] [message]
Russ Allbery [[email protected]] [message]
Intrigeri [[email protected]] [message]
Luca Filipozzi [[email protected]] [message]
Moritz Mühlenhoff [[email protected]] [message]
Paul Tagliamonte [[email protected]] [message]
Jordi Mallach [[email protected]] [message]
Philipp Kern [[email protected]] [message]
Holger Levsen [[email protected]] [message]
Jeremy Bicha [[email protected]] [mmessage]

Choix 1 : F : priorité à systemd

Cette résolution est une déclaration de position, selon le paragraphe section 4.1 (5) de la constitution de Debian :

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.

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émarrage ne l'emportent pas sur ses coûts.

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é en 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.

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.

Déposant de la proposition B

Sam Hartman [[email protected]] [texte de la proposition] [amendement]

Parrains de la proposition B

Cet amendement a été soumis par le Responsable actuel du projet et n’a donc pas besoin d’être soutenu.

Proposition B

Choix 2 : B : systemd mais nous encourageons l’exploration des alternatives

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.

Le projet Debian reconnaît que les unités de service (service units) 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.

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.

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.

Déposant de la proposition A

Sam Hartman [[email protected]] [texte de la proposition] [amendement] [amendement] [amendement]

Parrains de la proposition A

Cet amendement a été soumis par le Responsable actuel du projet et n’a donc pas besoin d’être soutenu.

Proposition A

Choix 3 : A : la prise en charge de plusieurs systèmes de démarrage est importante

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.

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 conduite NMU, les développeurs peuvent appliquer des non-maintener upload pour corriger ces bogues.

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.

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.

Déposant de la proposition D

Ian Jackson [[email protected]] [texte de la proposition] [texte d'amendement] [texte d'amendement] [texte d'amendement]

Parrains de la proposition D

Russ Allbery [[email protected]] [message]
Sean Whitton [[email protected]] [message]
Simon Richter [[email protected]] [message]
Kyle Robbertze [[email protected]] [message]
Dmitry Bogatov [[email protected]] [message]
Jonathan McDowell [[email protected]] [message]
Matthew Vernon [[email protected]] [message]
James Clarke [[email protected]] [message]
Thomas Goirand [[email protected]] [message]
Jonathan Dowland [[email protected]] [message]

Proposition D

Choix 4 : D : prise en charge des systèmes non systemd, sans bloquer l'évolution

PRINCIPES

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.

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.

DÉPENDANCES DE SYSTEMD

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.

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ée comme un bogue officiel dans le système de bogue de Debian, lorsqu'il n'y a pas de correctif disponible.

5. Qu'un paquet voit ses fonctionnalités réduites en l'absence de systemd ne devrait pas en général être répertorié comme utilisant une dépendance (Depends) ou une recommandation (Recommends) 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.

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.

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.

LES CONTRIBUTIONS DE PRISE EN CHARGE NON SYSTEMD SERONT ACCEPTÉES

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 de démarrage ne doivent 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”.

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

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

OUTILS DÉCLARATIFS DE SYSTEMD NON LIÉS AU DÉMARRAGE

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.

En général des approches plus déclaratives sont meilleures. Lorsque :

systemd fournit un outil de ce type,
il existe une spécification de l'outil (ou d'un sous-ensemble adapté),
l'outil est meilleur que d'autres approches disponibles dans Debian, par exemple en étant plus déclaratif,
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ée,

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

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.

ÊTRE CONCILIANTS LES UNS AVEC LES AUTRES

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.

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.

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.

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

Déposant de la proposition H

Ian Jackson [[email protected]] [texte la proposition]

Parrains de la proposition H

Jonas Smedegaard [[email protected]] [message]
Holger Levsen [[email protected]] [message]
Michael Lustfield [[email protected]] [message]
Guilhem Moulin [[email protected]] [message]
Matthew Vernon [[email protected]] [message]
Kyle Robbertze [[email protected]] [message]
gregor herrmann [[email protected]] [message]
Sean Whitton [[email protected]] [message]

Proposition H

Choix 5 : H : prendre en charge la portabilité sans bloquer les progrès

PRINCIPES

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.

2. Nous considérons que la portabilité vers 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.

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.

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éduisant ces désaccords grâce à des moyens techniques, aussi longtemps qu'il y aura des gens souhaitant fournir un effort.

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

DÉPENDANCES DE SYSTEMD

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.

7. Aussi échouer à prendre en charge des systèmes non systemd, où rien de tel n'existe, 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ée comme un bogue officiel dans le système de bogue de Debian, lorsqu'il n'y a pas de correctif disponible.

8. Qu'un paquet voit ses fonctionnalités réduites en l'absence de systemd ne devrait pas en général être répertorié comme utilisant une dépendance (Depends) ou une recommandation (Recommends) 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.

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.

LES CONTRIBUTIONS DE PRISE EN CHARGE NON SYSTEMD SERONT ACCEPTÉES

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), devrait être traité comme un bogue critique pour la publication. Par exemple, les scripts de démarrage ne doivent 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”.

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

OUTILS DÉCLARATIFS DE SYSTEMD NON LIÉS AU DÉMARRAGE

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.

En général des approches plus déclaratives sont meilleures. Lorsque :

systemd fournit un outil de ce type,
il existe une spécification de l'outil (ou d'un sous-ensemble adapté),
l'outil est meilleur que d'autres approches disponibles dans Debian, par exemple en étant plus déclaratif,
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ée,

ÊTRE CONCILIANTS LES UNS AVEC LES AUTRES

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.

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.

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

Déposant de la proposition E

Dmitry Bogatov [[email protected]] [texte de la dernière proposition]

Parrains de la proposition E

Ian Jackson [[email protected]] [message]
Matthew Vernon [[email protected]] [message]
Jonathan Carter [[email protected]] [message]
Kyle Robbertze [[email protected]] [message]
Axel Beckert [[email protected]] [message]
Brian Gupta [[email protected]] [message]
Simon Richter [[email protected]] [message]

Proposition E

Choix 6 : E : la prise en charge de plusieurs systèmes de démarrage est requise

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.

Déposant de la proposition G

Guillem Jover [[email protected]] [texte de la proposition]

Parrains de la proposition G

Simon Richter [[email protected]] [message]
gregor herrmann [[email protected]] [message]
Jonas Smedegaard [[email protected]] [message]
Guilhem Moulin [[email protected]] [message]
Ricardo Mones [[email protected]] [message]
Mathias Behrle [[email protected]] [message]
Steve Kostecke [[email protected]] [message]
Alberto Gonzalez Iniesta [[email protected]] [message]
Kyle Robbertze [[email protected]] [message]
Adam Borowski [[email protected]] [message]
Donald Scott Kitterman [[email protected]] [message]

Proposition G

Choix 7 : G : prise en charge de la portabilité et de multiples implémentations

Principes

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.

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.

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.

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éduisant ces désaccords grâce à des moyens techniques, aussi longtemps qu'il y aura des gens souhaitant fournir un effort.

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

Recommandations

De la même manière que les responsables Debian sont assez contraints par les décisions et l'orientation qui émanent de leurs équipes amont respectives, la distribution Debian est aussi assez entravée par sa nature reposant sur le volontariat qui est aussi un des traits principaux qui la définisse, ne souhaitant pas imposer d'obligations de travail à ses membres, tout en étant dans le même temps assujettie aux intérêts, motivation, énergie et temps limités de ses membres.

Du fait des contraintes précédemment exposées, tenter de fournir des recommandations d'une manière très détaillée pour l'application des principes susmentionnés, ne sera jamais satisfaisant, puisque cela finira inexorablement par être une liste rigide et non exhaustive de directives qui probablement ne peuvent jamais couvrir la plupart des scénarios, ce qui peut perpétuer les tensions possibles actuelles.

Cela continuera à impliquer des compromis au cas par cas sur quelles modifications ou requêtes de l'amont devraient être ou non acceptées, ou l'entretien des deltas imposés ou des implémentations que les membres de Debian pourraient devoir maintenir, ce qui ne peut jamais être quantifié et listé d'une manière générique et universelle.

Nous garderons aussi à l'esprit que ce qui pourrait être considéré comme important pour quelqu'un, pourrait en même temps être considéré comme un créneau ou un détournement de temps inintéressant pour quelqu'un d'autre, mais que nous devrions décider en étant de l'autre côté de la barrière lors de l'envoi ou la réception de ces requêtes.

Nous serons guidés, comme nous l'avons été dans bien d'autres contextes de Debian dans le passé, par la prise en compte de tout ce qui est mentionné ci-dessus, par la discussion et l'évaluation de chaque situation, et en respectant et accordant de l'importance au fait que nous avons tous des motivations et des intérêts différents. Ce qui est notre intérêt général est d'essayer d'arranger les choses avec les autres, de faire des compromis, de parvenir à des solutions ou trouver des alternatives qui pourraient être suffisamment satisfaisantes pour les différentes parties concernées, de créer un environnement où nous essaierons collectivement d'agir avec réciprocité. Et en fin de compte et dans la plupart des cas, il s'agit peut-être juste d'être prêt à essayer.

Déposant de la proposition C

Sam Hartman [[email protected]] [texte de la proposition] [amendement] [retrait]

Parrains de la proposition C

Cet amendement a été soumis par le Responsable actuel du projet et n’a donc pas besoin d’être soutenu.

Ansgar Burchardt [[email protected]] [message]

Proposition C

Priorité à systemd comme système de démarrage et autres outils (retiré)

Quorum

Avec la liste actuelle des développeurs ayant voté, nous avons :

 Nombre actuel de développeurs = 1011
 Q (racine carrée(nb de développeurs)) / 2 ) = 15.8981130955846
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 47.6943392867539

Quorum

L'option 1 a atteint le quorum : 307 > 47.6943392867539
L'option 2 a atteint le quorum : 299 > 47.6943392867539
L'option 3 a atteint le quorum : 225 > 47.6943392867539
L'option 4 a atteint le quorum : 281 > 47.6943392867539
L'option 5 a atteint le quorum : 271 > 47.6943392867539
L'option 6 a atteint le quorum : 173 > 47.6943392867539
L'option 7 a atteint le quorum : 216 > 47.6943392867539

Données et statistiques

Pour cette résolution générale, comme d'habitude, des statistiques 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 de compte pourra être aussi consultée.

Majorités requises

Les propositions ont besoin d’une majorité simple.

Majorité

L'option 1 obtient la majorité. 2.791 (307/110) >= 1
L'option 2 obtient la majorité. 2.694 (299/111) >= 1
L'option 3 obtient la majorité. 1.355 (225/166) >= 1
L'option 4 obtient la majorité. 2.465 (281/114) >= 1
L'option 5 obtient la majorité. 2.185 (271/124) >= 1
Renoncement à l’option 6 pour cause de majorité. 0.808 (173/214) <= 1
L'option 7 obtient la majorité. 1.286 (216/168) >= 1

Résultat

Dans le graphique ci-dessus, les nœuds en rose n'ont pas obtenu la majorité requise, le bleu est le gagnant. L’octogone est utilisé pour les options qui n’ont pas battu l'option par défaut

Option 1 "F : priorité à systemd"
Option 2 "B : systemd mais nous encourageons l’exploration des alternatives"
Option 3 "A : la prise en charge de plusieurs systèmes de démarrage est importante"
Option 4 "D : prise en charge des systèmes non systemd, sans bloquer l'évolution"
Option 5 "H : prendre en charge la portabilité sans bloquer les progrès"
Option 6 "E : la prise en charge de plusieurs systèmes de démarrage est requise"
Option 7 "G : prise en charge de la portabilité et de multiples implémentations"
Option 8 "poursuivre le débat"

Dans le tableau suivant, la correspondance ligne[x] colonne[y] représente le nombre de suffrages où l'option x est classé devant l'option y. Une explication plus détaillée de la matrice des gagnants peut vous aider à comprendre ce tableau. Pour comprendre la méthode Condorcet, l'entrée de Wikipedia est assez instructive.

**Grille des résultats**
	Option
	1	2	3	4	5	6	7	8
Option 1		185	246	223	227	278	243	307
Option 2	207		243	211	216	286	240	299
Option 3	159	131		113	120	250	165	225
Option 4	192	177	235		137	309	261	281
Option 5	187	168	222	163		301	246	271
Option 6	116	104	88	53	51		121	173
Option 7	168	145	176	93	91	207		216
Option 8	110	111	166	114	124	214	168

En regardant à la ligne 2, colonne 1, B : systemd mais nous encourageons l’exploration des alternatives
est classé devant F : priorité à systemd sur 207 bulletins.

En regardant à la ligne 1, colonne 2, F : priorité à systemd
est classé devant B : systemd mais nous encourageons l’exploration des alternatives sur 185 bulletins.

Couples de défaites

L'option 2 bat l'option 1 by ( 207 - 185) = 22 votes.
L'option 1 bat l'option 3 by ( 246 - 159) = 87 votes.
L'option 1 bat l'option 4 by ( 223 - 192) = 31 votes.
L'option 1 bat l'option 5 by ( 227 - 187) = 40 votes.
L'option 1 bat l'option 7 by ( 243 - 168) = 75 votes.
L'option 1 bat l'option 8 by ( 307 - 110) = 197 votes.
L'option 2 bat l'option 3 by ( 243 - 131) = 112 votes.
L'option 2 bat l'option 4 by ( 211 - 177) = 34 votes.
L'option 2 bat l'option 5 by ( 216 - 168) = 48 votes.
L'option 2 bat l'option 7 by ( 240 - 145) = 95 votes.
L'option 2 bat l'option 8 by ( 299 - 111) = 188 votes.
L'option 4 bat l'option 3 by ( 235 - 113) = 122 votes.
L'option 5 bat l'option 3 by ( 222 - 120) = 102 votes.
L'option 7 bat l'option 3 by ( 176 - 165) = 11 votes.
L'option 3 bat l'option 8 by ( 225 - 166) = 59 votes.
L'option 5 bat l'option 4 by ( 163 - 137) = 26 votes.
L'option 4 bat l'option 7 by ( 261 - 93) = 168 votes.
L'option 4 bat l'option 8 by ( 281 - 114) = 167 votes.
L'option 5 bat l'option 7 by ( 246 - 91) = 155 votes.
L'option 5 bat l'option 8 by ( 271 - 124) = 147 votes.
L'option 7 bat l'option 8 by ( 216 - 168) = 48 votes.

Contenu de l'ensemble de Schwartz

Option 2 "B : systemd mais nous encourageons l’exploration des alternatives"

Gagnant

Option 2 "B : systemd mais nous encourageons l’exploration des alternatives"

Debian utilise la méthode Condorcet pour les votes. De façon très simpliste, la méthode Condorcet pure pourrait s'expliquer ainsi :
Considérer tous les couples possibles de candidats. Le gagnant selon Condorcet, s'il existe, est le candidat qui bat chacun des autres candidats en duel singulier. Le problème est que dans des élections complexes, il pourrait y avoir des relations circulaires dans lesquels A bat B, B bat C et C bat A. La plupart des variations de la méthode Condorcet utilisent divers moyens pour résoudre ces cas. Veuillez lire la méthode Schulze pour de plus amples informations. La variante de Debian est expliquée dans la constitution, au paragraphe A.6.

Secrétaire du projet Debian