Table des matières
Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de la maintenance de paquets. Ce chapitre contient des informations sur les façons, souvent vraiment importantes, de contribuer à Debian au-delà de la simple création et maintenance de paquets.
En tant qu'organisation de volontaires, Debian repose sur la liberté de choisir ce sur quoi l'on désire travailler et de choisir la partie la plus importante à laquelle on veut consacrer son temps.
Nous vous encourageons à signaler des bogues quand vous en trouvez dans les paquets Debian. En fait, les développeurs Debian sont souvent les testeurs de première ligne. Trouver et signaler les bogues dans les paquets d'autres développeurs améliore la qualité de Debian.
Lisez les instructions pour signaler un bogue dans le système de suivi des bogues Debian.
Essayez de signaler un bogue à partir d'un compte utilisateur normal avec lequel vous pouvez recevoir des courriers, pour que les personnes puissent vous joindre si elles ont besoin de plus d'informations à propos du bogue. Ne signalez pas de bogues en tant que root.
Vous pouvez utiliser un outil comme reportbug(1) pour signaler des bogues. Il peut automatiser et dans l'ensemble faciliter le processus.
Assurez-vous que le bogue n'a pas déjà été signalé. Chaque paquet dispose
d'une liste de bogues facilement accessible à
http://bugs.debian.org/
.
Des outils comme querybts(1) peuvent également vous fournir ces
informations (et reportbug invoquera également
normalement querybts avant l'envoi).
nomdupaquet
Essayez d'envoyer vos bogues au bon endroit. Quand, par exemple, votre bogue concerne un paquet qui écrase des fichiers d'un autre paquet, vérifiez les listes des bogues pour les deux paquets afin d'éviter de créer des rapports de bogues dupliqués.
Vous pouvez également parcourir les bogues d'autres paquets, en les
regroupant s'ils sont indiqués plus d'une fois, ou en les marquant avec
« fixed
» quand ils ont déjà été corrigés. Notez
cependant que si vous n'êtes ni le rapporteur du bogue, ni le responsable du
paquet, vous ne devriez pas fermer réellement le bogue (à moins d'avoir
obtenu la permission du responsable).
De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos
des bogues que vous avez signalés. Saisissez cette occasion pour fermer les
bogues que vous ne pouvez plus reproduire. Pour trouver tous les bogues que
vous avez signalés, vous avez simplement besoin de vous rendre à la page
http://bugs.debian.org/from:
.
votre-adresse-de-courrier
Signaler de nombreux bogues pour le même problème sur un grand nombre de
paquets — plus de dix — est une pratique déconseillée. Prenez toutes les
mesures possibles pour éviter cette situation. Si le problème peut être
détecté automatiquement par exemple, ajoutez un nouveau test dans le paquet
lintian
pour générer une erreur ou
un avertissement.
Si vous voulez signaler plus de dix rapports sur le même sujet, il est
préférable d'indiquer votre intention sur la liste <debian-devel@lists.debian.org>
et
de le mentionner dans le sujet de votre message. Cela donnera à d'autres
développeurs la possibilité de vérifier que le problème existe vraiment. De
plus, cela permet d'éviter que plusieurs responsables ne rédigent les mêmes
rapports de bogue simultanément.
Veuillez utiliser les programmes dd-list et si
nécessaire, whodepends (du paquet devscripts
) pour générer une liste de tous les
paquets concernés et incluez la sortie dans votre courrier à
<debian-devel@lists.debian.org>
.
Quand vous envoyez un grand nombre de rapports sur le même sujet, vous
devriez les envoyer à <maintonly@bugs.debian.org>
pour éviter
qu'ils soient renvoyés vers les listes de diffusion.
Vous pouvez utiliser les étiquettes d'utilisateur du BTS lors du signalement
de bogues sur un grand nombre de paquets. Les étiquettes d'utilisateur se
comportent de la même façon que les étiquettes « patch
»
et « wishlist
» à la différence qu'elles sont définies
par l'utilisateur et occupe un espace de définition spécifique propre à
l'utilisateur. Cela permet à plusieurs groupes de développeurs de marquer
« Usertags
» le même bogue de différentes façon sans
conflit.
Pour ajouter des étiquettes d'utilisateur lors du signalement de bogues,
précisez les pseudo-entêtes User
et
Usertags
:
To: submit@bugs.debian.org Subject:titre-du-bogue
Package:nom-de-paquet
[ ... ]
User:adresse-mail
Usertags:nom-d-etiquette [ nom-d-etiquette ... ]
description-du-bogue ...
Remarquez que les étiquettes sont séparées par des espaces et ne peuvent
contenir de tiret bas. Si vous signalez des bogues au nom d'un groupe ou une
d'équipe spécifique, il vaut mieux définir User
comme une
liste diffusion appropriée après y avoir décrit votre intention.
Pour voir les bogues marqués par une étiquette d'utilisateur en particulier,
rendez-vous sur la page
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=
.
adresse-mail
&tag=nom-d-etiquette
Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité, les
devoirs de QA
ne leur sont pas exclusivement
réservés. Vous pouvez participer à cet effort en conservant vos paquets
aussi exempts de bogues que possible et aussi corrects que possible selon
lintian (voir Section A.2.1, « lintian
»). Si cela vous
paraît impossible, vous devriez alors envisager d'abandonner certains de vos
paquets (voir Section 5.9.4, « Abandon de paquet »). Sinon, vous pouvez demander de
l'aide à d'autres personnes pour qu'elles puissent rattraper votre retard
dans la correction des bogues (vous pouvez demander de l'aide sur
<debian-qa@lists.debian.org>
ou <debian-devel@lists.debian.org>
). En même temps, vous pouvez
rechercher des co-responsables (voir Section 5.12, « Maintenance collective »).
De temps en temps, le groupe d'assurance qualité organise des chasses aux
bogues (« Bug Squashing Party
») pour essayer de
supprimer le plus de problèmes possible. Elles sont annoncées sur
<debian-devel-announce@lists.debian.org>
en précisant quel domaine sera visé pendant la
chasse : habituellement, il s'agit des bogues empêchant l'intégration du
paquet dans la distribution (bogues de gravité « Release
Critical
»), mais il peut être décidé d'aider à finir une
transition majeure (comme une nouvelle version de Perl qui demande la
recompilation de tous les modules binaires).
Les règles pour les mises à jour indépendantes (NMU
) sont
différentes au cours de la chasse parce que l'annonce de la chasse est
considérée comme une annonce préalable pour les NMU. Si vous avez des
paquets qui peuvent être affectées par la chasse (parce qu'ils ont des
bogues critiques par exemple), vous devriez envoyer une mise à jour pour
chaque bogue correspondant pour expliquer leur état actuel et ce que vous
attendez de la chasse. Si vous ne voulez pas de NMU, si vous n'êtes
intéressé que par un correctif, ou si vous voulez gérer vous-même le bogue,
veuillez l'expliquer dans le BTS.
Les personnes qui participent à la chasse ont des règles spécifiques pour
les NMU, elles peuvent en faire une sans avertissement préalable si elles
envoient leur paquet avec un délai d'au moins trois jours dans
DELAYED/3-day
. Toutes les autres règles de NMU
s'appliquent comme d'habitude ; le correctif de la NMU devrait être envoyé
dans le BTS (pour l'un des bogues ouverts corrigé par la NMU ou pour un
nouveau bogue marqué corrigé). Les participants devraient également
respecter tout souhait du responsable s'il en a exprimé.
Si vous ne vous sentez pas à l'aise avec une NMU, envoyez simplement un correctif au BTS. C'est de loin meilleur qu'une NMU défectueuse.
Pendant vos activités dans Debian, vous contacterez d'autres responsables pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez simplement rappeler à quelqu'un qu'une nouvelle version est disponible et que vous en avez besoin.
Chercher l'adresse d'un responsable d'un paquet peut être
fastidieux. Heureusement, il existe un alias de courrier simple,
, qui
fournit un moyen d'envoyer un courrier à un responsable, quelle que soit son
adresse (ou ses adresses). Remplacez paquet
@packages.debian.orgpaquet
par
le nom du paquet source ou binaire.
Vous pouvez également vouloir contacter les personnes inscrites à un paquet
source donné, cf. Section 4.10, « Système de suivi des paquets (PTS
) ». Vous pouvez le
faire en utilisant l'adresse
.
paquet
@packages.qa.debian.org
Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer que le responsable est toujours actif et qu'il continue à travailler sur ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il n'ait pas démissionné du système. D'un autre côté, il est possible qu'il ait simplement besoin d'un rappel.
Il y a un système simple (la base de données MIA
) dans
laquelle les informations sur les responsables supposés manquant à l'appel
(« Missing In Action
») sont enregistrées. Quand un
membre du groupe QA
contacte un responsable inactif ou
trouve plus d'informations sur celui-ci, un enregistrement dans la base de
données MIA a lieu. Ce système est disponible dans
/org/qa.debian.org/mia
sur l'hôte
qa.debian.org
et peut être interrogé avec
mia-query. Utilisez mia-query --help
pour voir comment interroger la base de données. Si aucune information n'a
encore été enregistrée pour un responsable inactif ou si pour ajouter plus
d'informations, vous deviez utiliser la procédure suivante.
La première étape est de contacter poliment le responsable et d'attendre une réponse pendant un temps raisonnable. Il est assez difficile de définir le « temps raisonnable », mais il est important de prendre en compte que la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait être d'envoyer un rappel après deux semaines.
Si le responsable ne répond pas après quatre semaines (un mois), on peut supposer qu'il n'y aura probablement pas de réponse. Si ceci se produit, vous devriez poursuivre vos investigations et essayer de réunir toutes les informations utiles sur ce responsable. Ceci inclut :
les informations « echelon
» disponibles dans la base de données LDAP des développeurs, qui
indiquent quand le développeur a envoyé un message pour la dernière fois sur
une liste de diffusion Debian (cela inclut les envois via les listes
<debian-devel-changes@lists.debian.org>
). Pensez aussi à vérifier si le responsable est
indiqué comme en vacances dans la base de données ;
le nombre de paquets de ce responsable et l'état de ces paquets. En particulier, reste-t-il des bogues empêchant l'intégration du paquet dans la distribution qui sont ouverts depuis des lustres ? De plus, combien de bogues y a-t-il en général ? Un autre point d'information important est si les paquets ont subi des NMU, et si oui, par qui ;
est-ce que le responsable est actif en dehors de Debian ? Par exemple, il peut avoir envoyé des messages récemment à des listes de diffusion non-Debian ou des groupes de discussion ;
Un problème particulier est représenté par les paquets parrainés — le
responsable n'est pas un développeur Debian officiel. Les informations
« echelon
» ne sont pas disponibles pour les personnes
parrainées, par exemple ; vous devez donc trouver et contacter le
responsable Debian qui a réellement envoyé le paquet. Étant donné qu'il a
signé le paquet, il est responsable de l'envoi de toute façon et il sait
probablement ce qui s'est passé avec la personne qu'il parraine.
Il est également permis d'envoyer une demande à <debian-devel@lists.debian.org>
demandant si quelqu'un a des informations sur le responsable
manquant. Veuillez mettre en CC
la personne en question.
Une fois réunies toutes ces informations, vous pouvez contacter
<mia@qa.debian.org>
. Les personnes de cet alias utiliseront les informations que
vous aurez fournies pour décider comment procéder. Par exemple, elles
peuvent abandonner tout ou partie des paquets du responsable. Si un paquet a
subi une NMU, elles peuvent préférer contacter le responsable ayant fait
cette NMU — il pourrait être intéressé par le paquet.
Un dernier mot : veuillez rester poli. Tout le monde est volontaire et ne peut dédier l'intégralité de son temps à Debian. Vous n'êtes pas non plus au courant des conditions de la personne impliquée. Elle est peut-être sérieusement malade ou pourrait même nous avoir définitivement quitté — vous ne savez pas qui recevra vos courriers. Imaginez le sentiment d'un proche qui lit un courrier pour la personne décédée, et trouve un message très impoli, en colère et accusateur !
D'un autre côté, bien tout le monde soit volontaire, tout le monde est responsable. Vous pouvez donc insister sur l'importance du plus grand intérêt — si un responsable n'a plus le temps ou l'envie, il devrait « laisser filer » et donner le paquet à quelqu'un ayant plus de temps.
Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez étudier
le fichier README
dans
/org/qa.debian.org/mia
sur
qa.debian.org
où les détails techniques et les procédures
MIA sont documentées et contactez <mia@qa.debian.org>
.
Le succès de Debian dépend de sa faculté à attirer et conserver de nouveaux et talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous recommandons de vous impliquer dans le processus d'apport des nouveaux responsables. Cette section décrit comment aider les futurs développeurs.
Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est pas encore autorisé à le faire lui-même, un candidat au processus de nouveau responsable. Parrainer un paquet signifie aussi en accepter la responsabilité.
Les nouveaux responsables ont souvent quelques difficultés à créer des paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain est là pour vérifier que le paquet parrainé est assez bon pour être inclus dans Debian. (Si le paquet parrainé est nouveau, les responsables de l'archive devront également l'inspecter avant de l'intégrer).
Effectuer un parrainage en signant simplement l'envoi ou en recompilant le paquet n'est n'est définitivement pas recommandé. Vous devez construire le paquet source comme si vous vouliez construire l'un de vos paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du candidat développeur dans les fichier de modification et de contrôle, il est toujours possible de savoir que vous avez fait l'envoi.
Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
candidat gère la partie « Tâches et Capacités » (« Tasks and
Skills
») de sa candidature.
En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet respecte les standards minimum de Debian. Ceci implique que vous devez construire et tester le paquet sur votre propre système avant l'envoi.
Vous ne pouvez pas simplement envoyer un fichier .deb
binaire d'un filleul. En théorie, vous devriez seulement demander le fichier
diff
et l'emplacement de l'archive source d'origine et
ensuite vous devriez récupérer les sources et appliquer le diff
vous-même. En pratique, vous pouvez vouloir utiliser le paquet source
construit par votre filleul. Dans ce cas, vous devez vérifier qu'il n'a pas
modifié les sources amont dans le fichier
.orig.tar.{gz,bz2,lzma}
fourni.
N'hésitez pas à répondre au filleul et lui indiquer les changements à faire. Plusieurs échanges de courriers sont souvent nécessaires avant que le paquet ne soit dans un état acceptable. Être un parrain signifie être un mentor.
Quand le paquet respecte les standards Debian, construisez et signez le paquet avec :
dpkg-buildpackage -kKEY-ID
avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez
également utiliser toute partie de votre KEY-ID
,
tant qu'elle est unique dans votre trousseau secret.
Le champ Maintainer
du fichier
control
et le fichier changelog
devraient afficher la personne qui a fait l'empaquetage, c'est-à-dire, le
filleul. Celui-ci recevra donc tous les courriers du système de suivi des
bogues (BTS) à propos de son paquet.
Si vous préférez laisser une trace plus visible de votre travail de parrainage, vous pouvez ajouter une ligne l'indiquant dans la dernière entrée du journal de modification.
Vous devriez garder un œil sur le suivi des paquets que vous parrainez,
cf. Section 4.10, « Système de suivi des paquets (PTS
) ».
Les recommandations pour un développeur prospectif sont disponibles sur le site web de Debian.
La liste à vérifier pour les responsables de candidatures est disponible sur le site web de Debian.