Pour béta tester les nouvelles versions d’AbulÉduPRO il faut nous en faire la demande par courrier électronique à supportteam at ryxeo.com.

Avec l’agrandissement de l’équipe de RyXéo, Olivier a mis en place un certain nombre de procédures pour améliorer la qualité globale de notre travail, et surtout assurer un travail à plusieurs cohérent et efficace. Deux choses sont essentielles:

1. comprendre le processus de travail ;
2. savoir utiliser le bugtrack qui est la clé de voûte de tout ça.

Voici l’ordre normal des étapes de travail:

1. découverte du bug (la “surprise”)
2. ajout dans le bugtrack avec le plus de détails possibles → le bug est alors : “nouveau“, il vient d’être “rapporté”.
3. éventuellement un développeur requalifie le bug pour indiquer avec précision quel paquet ou quel code source il concerne.
4. une autre personne confirme le bug (elle arrive à le reproduire sur sa machine en suivant ce qu’a indiqué le rapporteur initial) ou n’arrive pas à le reproduire → le bug passe “confirmé” ou “incomplet”
5. un développeur “s’approprie” le bug confirmé, cherche et trouve une solution ou un contournement, il le marque donc “en cours” le temps de ce travail.
6. une fois le correctif terminé, le développeur passe le bug en “attente de packaging“. Cela veut dire que la solution est trouvée, mais qu’elle n’est pas encore rentrée dans un paquet Debian pour être installée partout.
7. le mainteneur du paquet Debian s’occupe donc d’inclure le correctif dans le ou les paquet(s) concerné(s) (quelques fois un problème fonctionnel est la conséquence d’une erreur entre deux programmes et il faut dans ce cas corriger les deux) et génère une nouvelle version de chaque paquet, puis l’envoie sur le serveur APT de validation (secure.ryxeo.com). Il passe alors le bug en “attente de validation” car le paquet doit être validé par une autre personne.
8. d’autres personnes mettent à jour leur serveur avec ce paquet et valident ou non la correction du problème ainsi que la bonne installation du paquet (Est-ce que ça casse autre chose quand le paquet s’installe ?). Si c’est bon un des testeurs marque le bug “en attente d’upload” pour indiquer que le paquet est prêt à être envoyé sur le serveur APT officiel, à disposition pour la mise à jour de tous les serveurs en production.
9. si le bug n’est pas corrigé, ou que le paquet Debian introduit un autre problème, le bug passe en “non validé” (avec un commentaire pour expliquer ce qui ne va pas), en attendant que le développeur ajuste son correctif ou que le mainteneur Debian adapte le paquet pour qu’il s’installe bien.
10. une fois que tous les bugs concernant un même paquet sont “en attente d’upload” (donc corrigés et validés), un mainteneur Debian envoie le paquet sur le serveur APT officiel et ferme le bug (état “résolu“).
11. les utilisateurs “normaux” (en production) peuvent lancer la mise à jour de leur serveur pour bénéficier de cette amélioration.

À partir du moment où vous faites partie du groupe des béta testeurs d’AbulÉdu PRO vous avez un accès sur un serveur FTP pour télécharger deux choses, d’une part le cédérom d’installation et d’autre part la documentation qui l’accompagne.

Tout ceci ne sera donc pas détaillé ici.

Lorsque vous rencontrez un bug ou quelque chose qui ne vous semble pas normal, dirigez-vous tout de suite sur le bugtrack pour vérifier que ce problème n’est pas déjà connu.

ATTENTION: le moteur de recherche intégré à eventum (le logiciel de bugtrack) n’est pas bon du tout (et encore je suis sympa), ne vous fiez donc pas à lui, utilisez plutôt la fonction rechercher de votre navigateur Web sur la page qui liste tous les bugs.

Ajoutez alors ce bug et décrivez-le de la manière la plus précise possible. Un responsable ou développeur de RyXéo améliorera sans doute cette déclaration par la suite mais plus vous êtes précis au départ et mieux c’est.

Si vous pouvez également fournir un jeu d’essai qui conduit au bug c’est génial.

Exemple de jeu d’essai:

1. lancer firefox
2. aller sur http://servecole
3. cliquer sur “administrer votre serveur”
4. entrer indentifiant et mot de passe
5. et là en bas de page j’observe un “warning” (détailler le warning, copier-coller le texte)

Note : un bug peut déjà être référencé, mais sous une appellation différente. Cela dépend souvent de qui le trouve. Exemple :

• bug qualifié par un utilisateur : « messages d’erreur pendant la mise à jour : il y a plein de messages “no such file or directory” pendant la mise à jour de mon serveur. »
• bug qualifié par un développeur ou un mainteneur Debian : « paquet ??? : manquent les redirections vers /dev/null dans le postinst. »

Ces deux qualifications désignent le même bug, car c’est l’oubli des redirections qui a entraîné l’affichage des messages d’erreur. C’est simplement le point de vue de la personne qui le rapporte qui change. Essayez donc de vous en souvenir quand vous recherchez un bug dans la base, car si vous ne le trouvez pas cela ne veut pas dire qu’il n’y est pas.

Les développeurs font des efforts pour qualifier les bugs avec des mots d’utilisateurs (les symptômes), mais ce sont les qualifications des causes qui sont le plus utiles pour résoudre le bug.

En cas de doute sur la présence d’un bug ou non dans la base, envoyez un courriel à devteam at ryxeo point com ou joignez-nous par Jabber pour nous poser la question. Si le bug n’y est effectivement pas, nous pourrons copier-coller le contenu de votre courriel pour ouvrir la déclaration de bug, ce qui évitera de dupliquer le travail.

La gestion de bug est un travail nécessaire pour avoir une traçabilité et un suivi qualité constants. La confirmation et la validation par des personnes différentes permettent d’éviter les erreurs au maximum. Ceci n’implique forcément pas que les bugs mettront longtemps à être résolus : quand nous travaillons en équipe (en local ou par Jabber), certains bugs ne mettent pas plus de 10 minutes pour traverser toute la chaîne de validation et être résolus / disponibles à la mise à jour. D’autres sont vraiment critiques ou dépendent de tellement de conditions qu’il est indispensable qu’ils soient validés par plusieurs personnes avant d’être mis à dispo.

Si le bug que je rencontre est déjà connu des déloppeurs, je vois si je peux améliorer la définition de celui-ci, fournir un jeu d’essai, aider à quelque chose de particulier.

Si dans la description il est indiqué la marche à suivre pour valider le paquet je fais ce qui est indiqué.

C’est là que vous pourrez nous aider le plus facilement, modifiez votre fichier /etc/apt/sources.list pour ajouter les deux lignes suivantes:

ATTENTION: ceci n’est valide que pour les BETA TESTEURS. Pour des serveurs en production il est hors de question de modifier votrer fichier sources.list et d’installer des paquets non validés, ils sont potentiellement dangereux.

deb http://secure.ryxeo.com/horizon/ dapper main restricted
deb-src http://secure.ryxeo.com/horizon/ dapper main restricted

Et ensuite vous pouvez suivre les étapes indiquées dans la description du bug pour installer le paquet concernant le bug et suivre le jeu d’essai.