[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ suivant ]
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 à remplir des rapports de bogue quand vous trouvez des bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent les testeurs de première ligne. Trouver et rapporter les bogues dans les paquets d'autres développeurs améliore la qualité de Debian.
Lisez les instructions
pour créer un rapport de bogue dans le système de suivi des bogues
Debian.
Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel vous pouvez recevoir des courriers, pour que les personnes puissent vous joindre s'ils ont besoin de plus d'informations à propos du bogue. Ne soumettez pas de bogues en tant que root.
Vous pouvez utiliser un outil comme reportbug(1) pour soumettre
des bogues. Il peut automatiser et dans l'ensemble faciliter le processus.
Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet dispose
d'une liste de bogues facilement accessible à
http://bugs.debian.org/nom_paquet. Des outils comme
querybts(1) peuvent également vous fournir ces informations (et
reportbug invoquera également habituellement querybts
avant l'envoi).
Essayez d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue concerne un paquet qui réécrit des fichiers d'un autre paquet, vérifiez les listes des bogues pour les deux paquets pour é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 que vous n'ayez 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 rapportés. Saisissez cette occasion pour fermer les bogues que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez rapportés, vous avez simplement besoin d'aller à http://bugs.debian.org/from:<votre-adresse-de-courrier>.
Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
paquets — plus de dix — est une pratique que nous
déconseillons. 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 ouvrez plus de dix rapports sur le même sujet, il est préférable
d'indiquer votre intention sur la liste [email protected]
et de mentionner le fait 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 à
[email protected].
Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
les envoyer à [email protected]
pour qu'ils ne soient pas redirigés vers les listes de diffusion.
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 (reportez-vous à lintian, Section A.2.1). Si
cela vous paraît impossible, vous devriez alors envisager d'abandonner certains
de vos paquets (reportez-vous à Abandonner un paquet, Section 5.9.4).
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 [email protected]
ou [email protected]).
En même temps, vous pouvez rechercher des co-responsables (reportez-vous à Maintenance collective, Section
5.12).
De temps en temps, le groupe d'assurance qualité organise des chasses aux
bogues[33] pour essayer de
supprimer le plus de problèmes possible. Elles sont annoncées sur [email protected]
et l'annonce explique quel domaine sera visé pendant la chasse :
habituellement, il s'agit des bogues empêchant l'intégration du paquet dans la
distribution (« Release Critical »), mais il peut arriver qu'ils
décident 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 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 mises à jour indépendantes. 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 d'une mise à jour indépendante ou 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 mises à jour indépendantes, ils peuvent en faire une sans avertissement préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans DELAYED/3-day. Toutes les autres règles de mise à jour indépendante s'appliquent comme d'habitude ; ils devraient envoyer le correctif de la mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également respecter tout souhait du responsable s'il en a exprimé.
Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante, envoyez simplement un correctif au BTS. C'est de loin meilleur qu'une mise à jour défectueuse.
Pendant vos activités dans Debian, vous aurez à contacter 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, <paquet>@packages.debian.org, qui fournit un moyen d'envoyer un courrier à un responsable, quelle que soit son adresse (ou ses adresses). Remplacez <paquet> par le nom du paquet source ou binaire.
Vous pouvez également vouloir contacter les personnes qui sont inscrites à un paquet de source donné par le Système de suivi des paquets, Section 4.10. 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 ne se soit pas désenregistré 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 Absents En Exercice (« Missing
In Action) sont enregistrées. Quand un membre du groupe QA contacte un
responsable inactif ou trouve plus d'informations sur celui-ci, c'est
enregistré dans la base de données MIA. Ce système est disponible dans
/org/qa.debian.org/mia sur l'hôte qa.debian.org et peut être interrogé avec un
outil de nom mia-query. Utilisez
mia-query --help
pour voir comment interroger la base de données. Si vous déterminez qu'aucune information n'a encore été enregistrée pour un responsable inactif ou si vous voulez 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-*-changes). Rappelez-vous également de vérifier si le responsable est
indiqué comme en vacances dans la base de données.
Le nombre de paquets de ce responsable et les conditions 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 mises à jour indépendantes 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 est probable qu'il sait ce qui s'est passé avec la personne qu'il parraine.
Il est également permis d'envoyer une demande à [email protected]
demandant si quelqu'un est au courant d'information sur le responsable
manquant. Veuillez mettre en CC: la personne en question.
Une fois que vous avez réuni toutes ces informations, vous pouvez contacter
[email protected]. Les
personnes de cet alias utiliseront les informations que vous aurez fournies
pour décider comment procéder. Par exemple, ils peuvent abandonner un ou tous
les paquets du responsable. Si un paquet a subi une mise à jour indépendante,
ils peuvent préférer contacter le responsable ayant fait cette mise à jour
— il est peut-être intéressé par le paquet.
Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes tous des volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian. Vous n'êtes pas non plus au courant des circonstances de la personne impliquée. Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté — vous ne savez pas qui recevra vos courriers. Imaginez comme un proche se sentira s'il 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 que nous soyons tous volontaires, nous avons une responsabilité. 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 [email protected].
Le succès de Debian dépend de sa capacité à attirer et retenir 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 nouveau responsable. Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
Les nouveaux responsables ont habituellement certaines 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. (Notez que si le paquet parrainé est nouveau, les ftpmasters devront également l'inspecter avant de l'intégrer)
Effectuer un parrainage en signant simplement l'envoi ou en recompilant le paquet 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 le changelog et dans le fichier de contrôle, il est toujours possible de savoir que c'est vous qui 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 »[34] de sa candidature.
En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet atteint 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
le source 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 fichiers sources du fichier
.orig.tar.gz qu'il fournit.
N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il doit faire. Cela prend souvent plusieurs échanges de courriers avant que le paquet ne soit dans un état acceptable. Être un parrain veut dire être un mentor.
Une fois que le paquet a atteint 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 porte-clés 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 plus récente entrée du changelog.
Vous êtes encouragé à garder un œil sur le suivi des paquets que vous parrainez en utilisant le Système de suivi des paquets, Section 4.10.
Reportez-vous à la page sur les recommandations pour un
développeur prospectif sur le site web Debian.
Veuillez vous reporter à la liste à vérifier pour
les responsables de candidatures sur le site web Debian.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ suivant ]
Référence du développeur Debian
[email protected][email protected]