3. Devoirs du développeur Debian

3.1. Devoirs du responsable de paquet

En tant que responsable de paquet, vous êtes censé fournir des paquets de haute qualité qui s'intégreront correctement dans le système et qui sont conformes à la Charte Debian.

3.1.1. Œuvrer pour la prochaine publication `stable`

Fournir des paquets de haute qualité dans unstable ne suffit pas, la plupart des utilisateurs ne profiteront de vos paquets que quand ils seront publiés avec la prochaine version stable. Vous êtes donc censé collaborer avec l'équipe en charge de la publication pour veiller à ce que vos paquets soient intégrés.

Plus concrètement, vous devriez surveiller si vos paquets migrent vers testing (consultez La distribution testing). Lorsque la migration n'a pas lieu après la période d'essai, vous devriez analyser pourquoi et œuvrer pour corriger cela. Votre paquet pourrait avoir besoin d'être corrigé (dans le cas de bogues critiques pour la publication ou d'échecs de construction sur certaines architectures) mais cela peut également signifier mettre à jour (ou corriger, ou supprimer de testing) d'autres paquets pour permettre de terminer une transition dans laquelle votre paquet est enchevêtré à cause de ses dépendances. L'équipe en charge de la publication devrait pouvoir vous renseigner sur ce qui bloque actuellement une transition donnée si vous ne parvenez pas à l'identifier.

3.1.2. Maintenance de paquets dans `stable`

La plupart du travail de responsable de paquet consiste à fournir des versions de paquets mis à jour dans unstable, mais son travail implique aussi de s'occuper des paquets dans la publication stable actuelle.

Même si les modifications dans stable sont déconseillées, elles sont possibles. Chaque fois qu'un problème de sécurité est signalé, vous devriez collaborer avec l'équipe en charge de la sécurité pour fournir une version corrigée (consultez Gestion des bogues de sécurité). Quand des bogues de sévérité important (ou plus) sont soumis sur la version stable de vos paquets, vous devriez envisager la possibilité de fournir une correction spécifique. Vous pouvez interroger l'équipe en charge de la publication stable pour savoir si elle accepterait une telle mise à jour puis préparer un envoi vers stable (consultez Cas particulier : distributions stable et oldstable).

3.1.3. Gestion des bogues critiques pour la publication

Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel que cela est décrit en Manipulation des bogues. Cependant, une catégorie spéciale de bogues nécessite particulièrement votre attention : les bogues critiques pour la publication (release-critical ou RC). Tous les rapports de bogue de gravité critical, grave ou serious rendent le paquet inapproprié pour être inclus dans la prochaine version stable. Ils peuvent donc retarder la publication de Debian (quand ils concernent un paquet de testing) ou bloquer des migrations vers testing (quand ils concernent seulement le paquet d'unstable). Au pire, ils pourraient conduire à la suppression du paquet. C'est pourquoi ces bogues doivent être corrigés au plus tôt.

Si pour une raison ou une autre, vous ne pouvez pas corriger un bogue critique pour la publication dans un de vos paquets en moins de deux semaines (par exemple à cause de contraintes de temps, ou parce que c'est compliqué à corriger) vous devriez le signaler clairement dans le rapport de bogue en l'étiquetant help pour encourager d'autres volontaires à s'impliquer. Sachez que les bogues critiques pour la publication sont souvent les cibles de mises à jour indépendantes (consultez Mises à jour indépendantes (NMU)) car ils peuvent bloquer la migration vers testing de plusieurs paquets.

Un manque d'attention aux bogues critiques pour la publication est souvent considéré par l'équipe d'assurance qualité comme un signe de disparition d'un responsable n'ayant pas abandonné correctement son paquet. L'équipe MIA pourrait aussi s'impliquer, avec comme éventuelle conséquence l'abandon de vos paquets (consultez Gestion des responsables non joignables).

3.1.4. Coordination avec les développeurs amont

Une grande part du travail de responsable Debian est de rester en contact avec les développeurs amont. Parfois, les utilisateurs signalent des bogues qui ne sont pas spécifiques à Debian. Ces rapports de bogue doivent être transmis aux développeurs amont pour une correction dans les versions suivantes. Habituellement, c'est ce qu'il y a de mieux à faire si vous le pouvez, sinon, vous pouvez demander à celui qui a soumis le bogue de le faire.

Bien qu'il ne soit pas de votre responsabilité de corriger les bogues non spécifiques à Debian, vous pouvez le faire si vous en êtes capable. Quand vous faites de telles corrections, assurez-vous de les envoyer également au développeur amont. Les utilisateurs et développeurs Debian proposent parfois un correctif pour les bogues amont, il vous faudra alors évaluer ce correctif puis le transmettre aux développeurs amont.

Dans le cas où un rapport de bogue est transmis au développeur amont, n'oubliez pas que le service bts-link peut aider à la synchronisation de l'état des bogues dans le système de suivi de bogues amont et celui de Debian.

Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un paquet conforme à la Charte Debian, vous devriez proposer un correctif aux développeurs amont pour qu'il soit inclus dans leur version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des mises à jour amont suivantes. Quels que soient les changements dont vous avez besoin, il faut toujours essayer de rester dans la lignée des sources amont.

Si vous estimez que les développeurs amont sont ou deviennent hostiles envers Debian ou la communauté du logiciel libre, vous pouvez vouloir reconsidérer le besoin d'inclure le logiciel dans Debian. Parfois, le coût social à la communauté Debian ne vaut pas le bénéfice que le logiciel peut apporter.

3.2. Devoirs administratifs

Un projet de la taille de Debian repose sur certaines structures administratives pour garder une trace de tout. En tant que membre du projet, vous avez quelques devoirs pour veiller à ce que tout se déroule sans problème.

3.2.1. Mise à jour des renseignements auprès de Debian

Une base de données LDAP contient des informations sur les développeurs Debian en https://db.debian.org/. Vous devriez y entrer vos informations et les mettre à jour quand elles changent. Le plus important est de vous assurer que l'adresse vers laquelle est renvoyée le courrier à destination de votre adresse debian.org est toujours à jour, de même que l'adresse à laquelle vous recevez votre abonnement à debian-private si vous choisissez d'être abonné à cette liste.

Pour plus d'informations sur cette base de données, veuillez consulter Base de données des développeurs.

3.2.2. Gestion de clé publique

Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un serveur public ou sur des machines multi-utilisateurs telles que les serveurs Debian (voir Serveurs Debian). Sauvegardez vos clés et gardez-en une copie hors connexion. Lisez la documentation fournie avec votre logiciel, la FAQ PGP et OpenPGP Best Practices.

Assurez-vous que votre clé est non seulement à l'abri des vols, mais aussi d'une perte. Générez et faites une copie (c'est même mieux sur papier) de votre certificat de révocation ; il est nécessaire si votre clé est perdue ou volée.

Si vous ajoutez des signatures à votre clé publique, ou des identifiants d’utilisateurs, vous pouvez mettre à jour le porte-clés Debian en envoyant votre clé au serveur de clefs à keyring.debian.org.Les mises à jour sont traitées au moins une fois par mois par les responsables du paquet debian-keyring.

Pour ajouter une nouvelle clé ou supprimer une ancienne clé, vous devez faire signer la nouvelle clé par un autre développeur. Si l'ancienne clé est compromise ou non valable, vous devez également ajouter le certificat de révocation. S'il n'y pas de bonne raison pour une nouvelle clé, les responsables du trousseau peuvent rejeter la nouvelle clé. Vous trouverez plus de détails en https://keyring.debian.org/replacing_keys.html.

Les mêmes routines d'extraction de clé décrites en Enregistrement comme responsable Debian s'appliquent.

Une présentation approfondie de la gestion de clé Debian peut être trouvée dans la documentation du paquet debian-keyring et sur le site https://keyring.debian.org/.

3.2.3. Votes

Bien que Debian ne soit pas vraiment une démocratie, le projet utilise un processus démocratique pour élire les responsables de projet et approuver les résolutions générales. Ces procédures sont définies par la constitution Debian.

En dehors de l'élection annuelle du responsable de projet, les votes ne se tiennent pas régulièrement et ne sont pas entrepris à la légère. Chaque proposition est tout d'abord discutée sur la liste de diffusion debian-vote@lists.debian.org et a besoin de plusieurs approbations avant que le secrétaire du projet n'entame la procédure de vote.

You don't have to track the pre-vote discussions, as the secretary will issue several calls for votes on debian-devel-announce@lists.debian.org (and all developers are expected to be subscribed to that list). Democracy doesn't work well if people don't take part in the vote, which is why we encourage all developers to vote. Voting is conducted via OpenPGP-signed/encrypted email messages.

La liste de toutes les propositions (passées et présentes) est disponible sur la page des informations sur les votes Debian, ainsi que des informations complémentaires sur la procédure à suivre pour effectuer une proposition, la soutenir et voter pour elle.

3.2.4. Départ en vacances poli

Il est courant que les développeurs s'absentent, que ce soit pour des vacances prévues ou parce qu'ils sont submergés de travail. L'important est que les autres développeurs ont besoin de savoir si vous êtes indisponible pour pouvoir agir en conséquence si un problème se produit sur vos paquets ou autre pendant votre absence.

Habituellement, cela signifie que les autres développeurs peuvent faire des NMU (voir Mises à jour indépendantes (NMU)) sur votre paquet si un gros problème (bogue empêchant l'intégration dans la distribution, mise à jour de sécurité, etc.) se produit pendant que vous êtes en vacances. Parfois, ce n'est pas très important, mais il est de toute façon approprié d'indiquer aux autres que vous n'êtes pas disponible.

Il y a deux choses à faire pour informer les autres développeurs. Premièrement, envoyez un courrier électronique à debian-private@lists.debian.org en commençant le sujet de votre message par « [VAC] » [1] et donnez la période de vos vacances. Vous pouvez également donner quelques instructions pour indiquer comment agir si un problème survenait.

L'autre chose à faire est de vous signaler comme en vacances (on vacation) dans la Base de données des développeurs (l'accès à cette information est réservé aux développeurs). N'oubliez pas de retirer l'indicateur on vacation à votre retour !

Ideally, you should sign up at the OpenPGP coordination pages when booking a holiday and check if anyone there is looking for signing. This is especially important when people go to exotic places where we don't have any developers yet but where there are people who are interested in applying.

3.2.5. Démission

Si vous décidez de quitter le projet Debian, veillez à procéder comme suit :

Abandonnez tous vos paquets comme décrit en Abandon de paquet ;
Retirez-vous des téléverseurs des paquets dont vous êtes co-responsable ou responsable en équipe.
Si vous recevez des courriels d’alias d’adresse @debian.org (p. ex. press@debian.org) et ne le désirez plus, ouvrez un ticket RT pour les administrateurs du système Debian (Debian System Administrators). Écrivez simplement à admin@rt.debian.org avec « Debian RT » dans le sujet et en déclarant de quel alias vous voulez être supprimé.
N'oubliez pas de vous retirer des équipes, par exemple des pages wiki des équipes ou des groupes de sala.
Connectez-vous à nm.debian.org en utilisant le lien https://nm.debian.org/process/emeritus, demandez le statut émérite et écrivez un message d'adieu qui sera envoyé automatiquement à la liste debian-private.

Authentication to the NM site requires an SSO browser certificate. You can generate them on https://sso.debian.org.

Au cas où vous rencontrez des difficultés pour initier le processus de démission, contactez le secrétariat des nouveaux membres (NM Front Desk) par un message à nm@debian.org.

Le processus précédemment décrit devrait absolument être suivi, car trouver les développeurs inactifs et déclarer orphelins leurs paquets est une tâche longue et fastidieuse.

3.2.6. Revenir après démission

Le compte d'un développeur est marqué « emeritus » (honoraire) quand le processus précédent en Démission est suivi, et « removed » (supprimé) sinon. Un développeur ayant démissionné avec un compte « emeritus » peut réactiver son compte de la façon suivante :

Get access to an salsa account (either by remembering the credentials for your old guest account or by requesting a new one as described at SSO Debian wiki page.
Pour obtenir davantage d'instructions, envoyez un message à nm@debian.org.
Passer un processus raccourci de nouveau responsable (pour s'assurer qu'il connaît toujours les parties importantes de « philosophie et procédures » et « tâches et compétences »).

Les développeurs ayant démissionné avec un compte « removed » doivent repasser le processus complet de nouveau membre.