D'un traducteur: ce texte est une traduction d'un article de blog personnel de Michael Stapelberg, un développeur open source de premier plan ( profil GitHub ), qui a apporté une contribution significative au développement de Debian.
Ce post a été difficile à écrire d'un point de vue émotionnel, mais je ne me suis pas limité à "une courte lettre, car je n'avais pas le temps". S'il vous plaît, avant de lire ce texte, gardez à l'esprit que je l'écris avec les meilleures intentions et ne me fixe pas pour objectif de démotiver ou de minimiser la contribution de l'un des développeurs. Je veux plutôt expliquer pourquoi mon niveau de frustration a dépassé toutes les valeurs acceptables.
Debian fait partie de ma vie depuis 10 ans.
Il y a quelques semaines, lors d'une réunion Debian à Zurich, j'ai rencontré mes anciens amis que je n'avais pas vus depuis de nombreuses années. Lorsque je conduisais déjà mon vélo chez moi, il m'est apparu que tous les sujets dont nous avions discuté se résumaient en quelque sorte à ce que nous avions discuté avec eux la dernière fois. Nous avons discuté des mérites de systemd, qui a une fois de plus attiré l'attention de la communauté open source, a abordé le sujet des processus dans Debian. Le point culminant a été la discussion sur la démocratie en tant que telle et les erreurs théoriques et pratiques correspondantes. Mais, en fait, c'est un sujet purement suisse.
Ce n'est pas une revue du passé mitap, je veux juste expliquer ce qui m'a fait penser à mon attitude actuelle envers Debian et si cela me convient.
J'ai donc pris une décision que je devais prendre longtemps: je limite ma participation au développement de Debian.
Qu'est-ce que cela signifie?
Au cours des prochaines semaines, les événements suivants se produiront:
- Je passerai les paquets importants à la commande maintenue;
- Je me retirerai des packages Uploaders qui contiennent d'autres mainteneurs;
- les colis dans lesquels j'étais la seule escorte deviendraient orphelins.
J'essaierai de continuer à maintenir les pages
manpages.debian.org et le service
codesearch.debian.net , mais j'apprécierai grandement toute aide dans ce domaine.
Si vous avez des questions ou des tâches, considérez que je suis en vacances pour une durée indéterminée. Je vais essayer de participer à certaines questions administratives (par exemple, le transfert de permis) et aux tâches qui me sont personnellement adressées, mais seulement si cela ne prend pas beaucoup de temps.
Pourquoi?
Quand j'ai rejoint Debian, j'étudiais encore, c'est-à-dire que j'avais beaucoup de temps libre. Maintenant, après cinq ans à temps plein, j'ai beaucoup appris - à la fois en termes de fonctionnement et de fonctionnement dans les grands projets de développement de logiciels, et en termes de compréhension de mes préférences personnelles dans les systèmes informatiques. Maintenant, je suis clairement conscient de ce que je passe sur cette petite partie de mon temps libre et de ce qu'il me reste à la fin de la journée.
Chacune des sections suivantes se concentrera sur les choses qui me blessent en tant que développeur. Cette liste est donnée dans un ordre aléatoire. Certains de ces problèmes s'influencent mutuellement, par exemple - si les modifications du système étaient mieux effectuées, nous aurions une chance que les colis soient plus faciles à manipuler par la machine.
Processus de changement de Debian
Au cours des dernières années, mon équipe actuelle a travaillé sur diverses réorganisations à travers la base de code (affectant des milliers de projets), nous avons donc reçu de nombreuses leçons précieuses sur la façon d'effectuer ces changements efficacement. Cela m'énerve que Debian fonctionne dans presque tous les sens et presque dans le sens inverse. J'apprécie le fait que chaque projet est différent, mais je pense que bon nombre des points énumérés ci-dessous s'appliquent à Debian dans son ensemble.
Chez Debian, le développement de paquets va dans la bonne direction en utilisant un document appelé la politique Debian, ou sa version logicielle
, Lintian .
Malgré le fait que la charpie soit très pratique pour obtenir un retour rapide direct ou local / autonome, il est encore mieux de ne pas avoir besoin d'un tel outil du tout. Par exemple, la commande C ++, qui introduit un nouvel indicateur de sécurité pour tous les packages, devrait également être en mesure de rendre son travail transparent (
à en juger par le profil GitHub, le langage principal de Go est Michael, environ Trans. ).
Au lieu de cela, maintenant tous les paquets sont faits «sales» (orig. - lint-unclean): tous les assistants devraient lire ce qu'est cette nouvelle chose, comment elle peut se casser, si cela affecte leur travail en général, et si oui, comment. Ensuite, vous devez exécuter manuellement certains tests et, enfin, ignorer les modifications. Tout cela est une multitude d'opérations mécaniques aériennes et manuelles entre les colis.
Dans le modèle Debian, la
décision de déployer les nouvelles appartient aux packages d'accompagnement, et non aux développeurs. Lors de mon travail principal, nous avons constaté qu'il était plus efficace de faire le contraire: si le changement écrit affecte une partie importante des utilisateurs, alors ce sont les développeurs qui doivent décider de la nécessité de sa mise en œuvre. Cette approche rend le développement du projet plus efficace et réduit les coûts de temps et de main-d'œuvre. Bien sûr, il y a des exceptions, par exemple, dans de grandes zones où des puces linguistiques sont utilisées, ce qui devrait être pris en charge par les conservateurs respectifs, mais l'important est que par défaut, tout devrait être différent de ce qu'il est maintenant.
Debian
manque d'outils pour effectuer des changements majeurs : il est difficile par programmation de travailler avec des paquets et des référentiels fragmentés (plus à ce sujet dans la section ci-dessous). L'événement le plus proche de «l'envoi de modifications à la révision» par défaut est le processus d'ouverture d'un rapport de bogue avec un correctif attaché. Il m'a semblé que le processus actuel d'acceptation d'une correction de bogue était trop compliqué, et j'ai commencé à travailler sur un bot de fusion, mais seul Guido et personne d'autre ne s'y sont intéressés (
apparemment, l'auteur parle de Guido agx Gunter , un autre développeur Debian, - env .
Pour le dire littéralement, la réaction à la poussée et, par conséquent, la réception des commentaires sont lentes. Il n'y a tout simplement aucun délai. Parfois, je reçois des e-mails m'informant que le patch que j'ai envoyé il y a plusieurs années (!!!) était enfin contenu. Cela étire les projets hebdomadaires pendant de nombreuses années, ce qui pour moi est un puissant démotivateur.
C'est curieux de le noter, mais la pratique de l'activité en ligne de la tortue est également projetée sur la culture hors ligne, et je ne veux pas discuter des avantages de systemd 10 ans après en avoir entendu parler pour la première fois.
Et enfin, tout changement peut être bloqué par ceux qui ne sont pas d'accord, qui refusent finalement de coopérer. Mon exemple canonique de cette situation est rsync. Le conservateur a refusé mes correctifs, qui ajoutent un support de debhelper au package, uniquement pour leurs propres convictions.
Accorder un tel degré de liberté personnelle aux responsables individuels empêche tous les participants au projet d'élever le niveau d'abstraction de la construction Debian, ce qui complique à son tour les outils de développement.
À quoi cela ressemblerait-il dans un monde idéal?
- En tant que projet, nous devons viser l'unification. Après tout, l'unification n'exclut pas les expériences; elle change simplement le compromis actuel entre des expériences plus simples et une automatisation plus complexe en un compromis entre des expériences plus complexes et une automatisation plus simple.
- Notre culture de développement devrait s'éloigner du paradigme «ce package est ma maison, comment osez-vous le toucher», un sens commun de la propriété, dans lequel tout participant peut facilement apporter ou vérifier des changements, même sans impliquer des conservateurs spécifiques qui les accompagnent.
Pour comprendre à quoi peuvent ressembler de grands changements (correctifs) réussis, je vous recommande de lire l'exposé de mon collègue Hyrum Wright,
«Les changements à grande échelle chez Google: leçons tirées des migrations de masse sur cinq ans» .
Flux de travail et infrastructure fragmentés
Debian préfère généralement les approches décentralisées aux approches centralisées. Par exemple, des packages séparés sont stockés dans des référentiels distincts, et chaque référentiel peut utiliser n'importe quel SCM (généralement git et svn) ou pas du tout. De plus, chaque référentiel peut être hébergé sur n'importe quel site. Bien sûr, le contenu de chaque référentiel varie également légèrement d'une équipe à l'autre, et même au sein de l'équipe.
Dans la pratique, les options d'hébergement non standard sont rarement utilisées, car elles ne justifient pas leur coût, mais souvent assez pour causer de grandes difficultés lors de l'automatisation du processus de modification des packages. Ainsi, au lieu d'utiliser l'API GitLab pour créer des demandes de fusion, vous devez développer un système complètement différent et plus complexe qui fonctionne avec des référentiels inaccessibles périodiquement (ou constamment!), Résume les différences dans les correctifs livrés (rapports d'erreur, demandes de fusion , demandes d'extraction), etc., etc.
Des processus de développement radicalement différents ne sont pas seulement une perte de temps. J'ai participé à de longues discussions sur divers processus de développement de git pendant DebConf 13 et j'ai réalisé que des discussions similaires se tenaient alors.
Personnellement, je ne peux pas garder à l’esprit suffisamment de détails sur les différentes méthodologies de développement. Chaque fois que je touche un paquet qui ne fonctionne pas comme le mien, je suis très contrarié parce que je dois réexaminer certains aspects de son travail.
J'ai remarqué une fragmentation similaire du flux de travail dans ma propre équipe d'emballage Go et j'ai essayé de le corriger en
faisant des suggestions de modifications au flux de travail , mais je n'ai pas pu les implémenter. Le manque d'automatisation efficace et le faible taux de changement des outils, malgré ma volonté de consacrer mon temps et mon énergie, ont tué toute motivation.
Infrastructure obsolète: télécharger des packages
Lorsque vous voulez rendre un paquet disponible dans Debian, vous téléchargez des fichiers signés GPG via FTP anonyme. Il existe plusieurs types de tâches (démon de file d'attente, non vérifiées, désinstallation et autres) qui s'exécutent selon un calendrier fixe (par exemple, la désinstallation s'exécute à 01:52 UTC, 07:52 UTC, 13:52 UTC et 19:52 UTC).
J'ai calculé qu'en fonction de l'heure de la journée, vous pouvez attendre plus de 7 heures (!!!) avant d'installer votre package.
Mais le pire pour moi, c'est que le feedback est asynchrone par rapport au chargement. J'aime faire quelque chose, y mettre fin et passer à la prochaine affectation. La configuration actuelle nécessite une longue attente et, en fait, un basculement coûteux entre les tâches sans bonnes raisons techniques. Vous remarquerez peut-être que quelques minutes n'ont pas vraiment d'importance, mais lorsque tout le temps d'une journée que je peux passer sur Debian est mesuré en minutes, il est très important de percevoir mes propres performances et satisfaction à partir du travail effectué.
Le dernier message que je peux trouver sur l'accélération de ce processus est un
article de George Ganneff Jaspert de 2008.
À quoi cela ressemblerait-il dans un monde idéal?
- Le FTP anonyme serait remplacé par un service Web qui accepte mon colis et renvoie dans sa réponse une décision officielle de l'accepter ou de le refuser.
- Pour les packages reçus, une page affiche l'état de la construction et l'heure à laquelle le package sera disponible via un réseau de miroirs.
- Les colis doivent être disponibles dans les minutes suivant la fin de l'assemblage.
Infrastructure obsolète: Bug Tracker
J'ai peur d'interagir avec le traqueur de bogues Debian. Debbugs est un morceau de code directement de 1994 qui n'est actuellement utilisé que par Debian et le projet GNU.
Les processus de débogage sont basés sur l'utilisation du courrier électronique, c'est-à-dire qu'ils sont asynchrones et encombrants. Malgré le fait qu'il fonctionne sur les machines les plus rapides que nous ayons sur le projet Debian (enfin, ils m'ont dit quand ce sujet a été soulevé pour la dernière fois), son interface web se charge extrêmement lentement.
Notamment, l'interface Web de bugs.debian.org est en lecture seule.
Configurer un
espace de
travail de messagerie pour
reportbug (1) ou travailler manuellement avec des pièces jointes est un défi assez sérieux.
Pour une raison que je ne comprends pas, chaque interaction avec les débogages entraîne de
nombreuses conversations .
Outre l'implémentation technique, je ne me souviens pas non plus des différentes manières dont Debian utilise les paquets de pseudo génération pour les erreurs et les processus. J'ai rarement besoin d'eux pour que je mette enfin tout cela dans ma tête et que je me souvienne de leur fonctionnement et de leur utilisation, mais je les rencontre parfois, donc cette variété est ennuyeuse.
À quoi cela ressemblerait-il dans un monde idéal?
- Debian passera d'un moyen non standard de suivi des bogues à (tout) déjà réglé.
- Debian automatise ces processus. L'interface principale devrait être plus pratique (par exemple, un formulaire Web).
Infrastructure obsolète: archives de la correspondance par courrier électronique
Je suis confus par le fait qu'en 2019, nous n'avons toujours pas d'outil pratique pour afficher les fils de discussion archivés par courrier. Aussi largement que dans Debian, le courrier électronique et les conversations ne sont plus utilisés nulle part, donc c'est même quelque peu ironique. L'utilisation de
Gmane semblait résoudre ce problème, mais sa disponibilité au cours des dernières années a été, pour le dire légèrement, abrupte (maintenant, au moment de la rédaction de cet article, cela ne fonctionne pas du tout).
J'ai essayé de créer une archive multi-thread, mais nos maîtres de feuilles n'ont pas été impressionnés et ont refusé de soutenir le projet.
Il est difficile pour les machines de travailler avec Debian
Bien qu'il soit évident que vous pouvez travailler avec des paquets Debian par programmation, cette expérience n'est guère agréable. Tout semble lent et encombrant. J'ai sélectionné trois petits exemples pour illustrer ma position sur cette question.
debiman a besoin de l'
aide de piuparts pour analyser le mécanisme alternatif de chaque paquet pour afficher les pages de documentation, par exemple,
PSQL (1) . Cela était nécessaire car les scripts modifient la base de données alternative en appelant des scripts shell. Mais sans réellement installer le package, vous ne saurez pas quels changements il apporte.
pk4 doit maintenir son propre cache pour rechercher des métadonnées de package en fonction de son nom. D'autres outils analysent la base de données apt à partir de zéro à chaque appel. Le format de base de données correct, ou au moins le format d'échange binaire, sera d'une grande importance pour ce processus.
Debian Code Search souhaite recevoir les nouveaux paquets le plus rapidement possible. L'instance
fedmsg était précédemment utilisée, mais elle n'existe plus. Il est difficile de savoir où recevoir des notifications de nouveaux packages et où il est préférable de les recevoir.
Pile de construction complexe
Ici, vous pouvez lire mon article
«Outils de construction de paquets Debian» . Ce qui m'inquiète vraiment, c'est que l'augmentation du nombre d'outils n'est pas considérée comme un problème.
Debian est une expérience douloureuse pour un développeur
La plupart des questions que j'ai soulevées concernent l'expérience de développement Debian, mais, comme je l'ai récemment décrit dans mon article
Debian Debug Debugging Experience , l'expérience de développement
avec Debian laisse également beaucoup à désirer.
J'ai plus d'idées
L'article s'est avéré assez volumineux, mais j'espère que vous avez une idée approximative de ma motivation.
Bien que j'aie décrit un certain nombre de défauts spécifiques ci-dessus, le dernier clou dans le couvercle du cercueil est l'absence de perspectives positives pour l'avenir. J'ai d'autres idées qui me semblent vraiment convaincantes, mais sur la base de la progression de mes projets précédents, je ne pense pas pouvoir les implémenter dans le cadre du projet Debian.
J'ai l'intention de publier quelques articles supplémentaires sur des moyens spécifiques d'améliorer les systèmes d'exploitation sur mon blog. Alors rendez-vous.
Et enfin, j'espère que ce billet inspirera quelqu'un, idéalement un groupe de personnes, pour améliorer la vie des développeurs Debian.