5. Le défi pour les mainteneurs d'un logiciel porté

Cette section vous donnera une idée de pourquoi les logiciels portés nécessitent qu'on les maintienne et met en évidence les responsabilités qui incombent au mainteneur d'un logiciel porté.

5.1. Pourquoi les logiciels portés nécessitent une maintenance

Créer un logiciel portés est une tâche ponctuelle dans le temps. S'assurer qu'un logiciel porté est à jour, compile, et s'exécute toujours correctement nécessite un effort de maintenance continu. Les mainteneurs sont des personnes qui consacrent une partie de leur temps à atteindre ce but.

La raison principale pour laquelle les logiciels portés nécessitent une maintenance est d'apporter à la communauté FreeBSD les tous derniers et meilleurs logiciels tiers disponibles. Un défi supplémentaire est de s'assurer que les logiciels portés continuent à fonctionner au sein de la structure du dépôt des logiciels portés lorsque celle-ci évolue.

En tant que mainteneur, vous devrez relever les défis suivants:

5.2. Les responsabilités du mainteneur

5.2.1. Maintenir ses logiciels portés à jour

Cette section expose la manière de procéder pour maintenir vos logiciels portés à jour.

Ceci est une vue d'ensemble. Des informations complémentaires sur la façon de mettre à jour un logiciel porté sont disponibles dans le Guide du Porteur d'applications.

  1. Surveillez les mises à jour

    Surveillez les sorties de nouvelles versions, mises à jour et correctifs de sécurité effectuées par l'éditeur du logiciel. Les listes diffusant les annonces ou les pages Web sont utiles pour cela. Parfois les utilisateurs vous contacteront et vous demanderont quand votre logiciel porté sera mis à jour. Si vous êtes occupé par d'autres tâches ou que vous n'êtes pas en mesure pour une raison ou une autre de le mettre à jour à ce moment, demandez-leur si ils peuvent vous aider en soumettant une mise à jour.

    Il se peut que vous receviez également un courrier électronique de la part du Vérificateur de version des logiciels portés de FreeBSD vous informant qu'une version plus récente du fichier distribution pour votre logiciel porté est disponible. De plus amples informations à propos de ce système (incluant les instructions pour ne plus recevoir de notification) seront fournies dans les messages.

  2. Intégrer les changements

    Lorsqu'ils sont disponibles, intégrez les changements à votre logiciel porté. Vous devez être en mesure de pouvoir générer un patch entre le logiciel porté original et celui mis à jour.

  3. Vérification et test

    Vérifiez minutieusement et testez vos changements:

    • Compilez, installez et testez votre logiciel porté sur autant de plates-formes et d'architectures que vous pouvez. Il est courant pour un logiciel porté de fonctionner sur une branche ou une plate-forme et d'échouer sur une autre.

    • Faites en sorte qu'il ne manque aucune dépendance à votre logiciel porté. Il est recommandé pour cela d'installer votre propre tinderbox. Consultez les ressources pour plus d'informations.

    • Vérifiez que la liste des fichiers du paquetage est à jour. Cela implique de rajouter tout nouveau fichier ou répertoire et de supprimer toutes les entrées non utilisées.

    • Vérifiez votre logiciel porté en utilisant portlint(1) comme guide. Consultez les ressources pour obtenir des informations importantes sur la manière d'utiliser portlint.

    • Prenez en considération le fait que des changements sur votre logiciel porté pourraient casser d'autres logiciels portés. Si tel est le cas, coordonnez les modifications avec les mainteneurs de ces autres logiciel portés. Ceci est d'autant plus important que votre mise à jour modifie une version de bibliothèque partagée, dans ce cas les logiciels portés dépendants auront au moins besoin d'une incrémentation de PORTREVISION pour qu'ils soient automatiquement mis à jour par des outils d'automatisation comme portupgrade(1).

  4. Soumettre les changements

    Envoyez votre mise à jour en soumettant un PR contenant les raisons de vos changements ainsi que le correctif contenant les différences entre le logiciel porté original et celui mis à jour. Référez-vous à Ecrire des rapports de problème FreeBSD pour obtenir des informations concernant la manière d'écrire un bon PR.

    Note : S'il-vous-plaît, ne soumettez pas une archive shar(1) du logiciel porté entier mais utilisez à la place diff(1) -ruN. De cette manière, les committers pourront bien plus facilement voir exactement les changements qui ont été faits. La section du Guide du Porteur d'applications sur la Mise à jour contient de plus amples informations à ce sujet.

  5. Soyez patient

    À un moment donné un committer s'occupera de votre PR. Cela peut prendre quelque minutes, ou quelques semaines — donc s'il-vous-plaît, soyez patient.

  6. Faites-nous un retour

    Si un committer détecte un problème avec vos changements, il vous le mentionnera très probablement. Une réponse rapide de votre part aidera à ce que votre PR soit pris en compte plus rapidement, et cela est mieux pour maintenir le fil de la discussion lorsque l'on essaie de résoudre un problème.

  7. Et Finalement

    Vos changements seront enregistrés et votre logiciel porté aura été mis à jour. Le PR sera alors fermé par le committer. Et voilà!

5.2.2. Assurez-vous que vos logiciels portés continuent à compiler correctement

Cette section concerne la découverte et la correction de problèmes qui empêchent vos logiciels portés de compiler correctement.

FreeBSD garantit seulement que le catalogue des logiciels portés fonctionne sur la branche -STABLE. Vous devriez utiliser 5-STABLE ou 6-STABLE, préférablement cette dernière. Théoriquement vous devriez être capable de vous en sortir en faisant tourner la dernière version de chacune des branches stables (car les ABI ne sont pas supposées changer) mais si vous pouvez utiliser la branche c'est encore mieux.

Etant donné que la majorité des installations de FreeBSD tourne sur des machines compatibles PC (ce que l'on appelle l'architecture i386), nous attendons de vous que vous assuriez le bon fonctionnement du logiciel porté sur cette architecture. Cependant, comme de plus en plus de personnes commencent à utiliser l'architecture amd64 en natif, il va devenir de plus en plus important de s'assurer que les logiciels portés fonctionnent sur celle-ci aussi. Il est parfaitement acceptable de demander de l'aide si vous n'êtes pas en possession d'une telle machine.

Note : Les causes de dysfonctionnement les plus courants sur les architectures non-i386 proviennent du fait que les programmeurs sont partis du principe que, par exemple, les pointeurs sont des ints, ou que le compilateur relativement laxiste gcc 2.95 a été utilisé. De plus en plus, les auteurs d'applications retravaillent leur code pour supprimer ce genre d'hypothèses — mais si l'auteur ne maintient pas activement son code, il se pourrait que vous ayez à le faire vous-même.

Voici les tâches dont vous devez vous acquitter pour vous assurer que votre logiciel porté peut être compilé:

  1. Surveillez les erreurs de compilation

    Vérifiez régulièrement les fermes de compilation automatique des logiciels portés, pointyhat, ainsi que le scanneur des fichiers distribution pour voir si un des logiciels portés que vous maintenez ne parvient pas à compiler ou ne peut télécharger l'archive dont il a besoin (voir ressources pour plus d'informations concernant ces systèmes). Des rapports d'erreurs peuvent également vous parvenir par courrier électronique en provenance d'autres utilisateurs ou systèmes automatisés.

  2. Collectez les informations

    Lorsque vous avez détecté un problème, collectez les informations vous permettant de le corriger. Les erreurs de compilation rapportées par pointyhat s'accompagnent de fichiers d'historique qui vous montreront l'endroit où l'erreur de compilation est survenue. Si le problème vous a été rapporté par un utilisateur, demandez-lui de vous envoyer les informations qui vous aideraient à diagnostiquer le problème, comme:

    • Les fichiers d'historique de compilation

    • Les commandes et options utilisées pour compiler le logiciel porté (incluant le jeu d'options présent dans /etc/make.conf)

    • La liste des paquets installés sur leur système tel qu'indiqué par pkg_info(1)

    • La version de FreeBSD qu'ils utilisent tel qu'indiqué par uname(1) -a

    • De quand date la dernière mise à jour de leur catalogue des logiciels portés

    • De quand date la dernière mise à jour de leur fichier INDEX

  3. Enquêtez et trouvez une solution

    Malheureusement il n'existe pas de processus simple pour cela mais souvenez-vous cependant que si vous êtes bloqué, demandez de l'aide! La liste de diffusion à propos du catalogue des logiciels portés de FreeBSD est un bon point de départ, et les développeurs en amont sont souvent très serviables.

  4. Soumettre les changements

    De la même manière que pour mettre à jour un logiciel porté, vous devriez inclure les changements, vérifier et tester, soumettre vos modifications dans un PR, et expliciter vos actions si besoin.

  5. Envoyez vos modifications aux auteurs

    Dans certains cas, il vous sera nécessaire de produire un correctif au logiciel porté pour qu'il fonctionne sur FreeBSD. Certains auteurs (mais pas tous) accepteront d'inclure de tels correctifs dans leur code pour la prochaine version. Dans ce cas, cela pourrait même être utile aux utilisateurs d'autres systèmes basés sur BSD et peut-être éviter des efforts redondants. Par courtoisie, prenez s'il-vous-plaît en considération l'envoi de vos correctifs aux auteurs du logiciel.

5.2.3. Analysez les rapports d'erreur et PRs liés à votre logiciel porté

Cette section concerne la découverte et la correction des bogues.

Les bogues spécifiques à FreeBSD proviennent généralement d'hypothèses faites sur les environnements de compilation et d'exécution qui ne s'appliquent pas à FreeBSD. Il est moins probable que vous rencontriez un problème de ce type, mais il se peut qu'il soit plus subtile et difficile à diagnostiquer.

Voici les tâches que vous devrez effectuer pour vous assurer que votre logiciel porté continue à fonctionner comme attendu:

  1. Répondre aux rapports de bogues

    Les bogues peuvent vous être rapportés par courrier électronique par l'intermédiaire de la base de données des rapports de problème GNATS. Les bogues peuvent également vous être rapportés directement par les utilisateurs.

    Vous devriez répondre aux PRs et autres rapports dans les 14 jours, mais s'il-vous-plaît faites votre possible pour ne pas prendre autant de temps pour répondre. Essayez de le faire aussi vite que possible, même si c'est juste pour dire que vous avez besoin d'un peu de temps avant de pouvoir travailler sur ce PR.

  2. Collectez les informations

    Si la personne rapportant le bogue n'a pas dans le même temps fourni de correctif, vous devez collecter les informations nécessaires qui vous permettront d'en produire un.

    Si le bogue est reproductible, vous pouvez collecter la plupart des informations nécessaires vous-même. Dans le cas contraire, demandez à la personne qui vous a rapporté le bogue de collecter les informations pour vous, comme:

    • Une description détaillée de leurs actions, le comportement attendu du programme ainsi que le comportement observé

    • Une copie des données d'entrée qui ont déclenché l'apparition du bogue

    • Les informations concernant leur environnement de compilation et d'exécution — par exemple, la liste des paquetages installés et la sortie de env(1)

    • Images mémoire (Core dumps)

    • Traces de la pile mémoire (Stack traces)

  3. Eliminez les rapports incorrects

    Certains rapports de bogues peuvent être incorrects. Par exemple, l'utilisateur peut tout simplement avoir mal utilisé le programme; ou bien les paquets qu'ils ont installés peuvent être obsolètes et nécessiter une mise à jour. Parfois un rapport de bogue n'est pas spécifique à FreeBSD. Rapportez dans ce cas le bogue aux développeurs en amont. Si vous avez les compétences requises pour résoudre le bogue, vous pouvez également corriger le logiciel porté de sorte que le correctif soit appliqué avant la diffusion par les développeurs de la version suivante du logiciel.

  4. Trouvez une solution

    Tout comme pour les erreurs de compilation, vous devrez trouver une solution au problème. A nouveau, souvenez-vous que vous pouvez demander de l'aide si vous êtes bloqué!

  5. Soumettez ou approuvez les changements

    Comme pour la mise à jour d'un logiciel porté, vous devriez intégrer vos changements, vérifier et tester, et soumettre vos modifications dans un PR (ou envoyer un suivi si un PR existe déjà pour ce problème). Si un autre utilisateur a soumis des changements dans le PR, vous pouvez également envoyer un suivi indiquant si vous approuvez ou non ces changements.

5.2.4. Fournir du support

Fournir du support fait partie des tâches incombant au mainteneur — pas pour le logiciel lui-même — mais pour son logiciel porté ainsi que tout problème lié à FreeBSD. Les utilisateurs peuvent prendre contact avec vous concernant des questions, suggestions, problèmes ou correctifs. La plupart du temps leur correspondance sera spécifique à FreeBSD.

Occasionnellement vous devrez faire appel à vos talents diplomatiques, et aimablement orienter les utilisateurs à la recherche de support général vers les ressources appropriées. Moins fréquemment vous rencontrerez une personne demandant pourquoi les RPMs ne sont pas à jour ou comment il peut faire pour faire fonctionner le logiciel sous Linux Untel. Profitez de l'occasion pour lui dire que votre logiciel porté est à jour (si il l'est, bien évidemment!), et suggérez-lui d'essayer FreeBSD.

Parfois les utilisateurs et développeurs considéreront que vous êtes une personne occupée dont le temps est précieux et ils prendront en charge une partie de votre travail. Ils pourraient par exemple:

  • soumettre un PR ou envoyer un correctif pour mettre à jour votre logiciel porté,

  • enquêter et peut-être proposer un correctif à un PR, ou bien

  • proposer une modification à appliquer à votre logiciel porté.

Pour ce genre de situations votre principale obligation est de répondre rapidement. Le délai maximum qu'a un mainteneur pour répondre est de 14 jours. Après cette période les changements peuvent être appliqués même sans accord. Les utilisateurs ont pris la peine de faire le travail pour vous donc s'il-vous-plaît essayez de leur répondre rapidement. Puis vérifiez, approuvez, modifiez ou discutez leurs changements avec eux dès que possible.

Si vous parvenez à leur faire sentir que leur contribution est appréciée (cela devrait être le cas) vous serez plus en mesure de les persuader de faire plus de choses pour vous à l'avenir :-).

Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.

Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.