La documentation du parfait Béta-testeur AbulÉdu

Avec la réorganisation du développement d'AbulÉdu initiée par RyXéo, Éric a mis en place un certain nombre d'outils et 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 la forge qui est la clé de voûte de tout notre travail;

Voici l'ordre normal des étapes de travail:

1. découverte du bug (la “surprise”)
2. choix du bon endroit où dépôser le bug:
   • si c'est lié au dvd d'installation c'est ici:
   • si c'est un bug de l'interface web d'administration c'est ici:
   • si c'est un logiciel du terrier c'est ici:
   • pour tout le reste c'est là:
   • si vous ne savez pas: parlez en sur la liste beta @ abuledu.org !
3. dépôsez le bug avec le plus de détails possible et surtout permettez nous de le reproduire, imaginez que nous sommes aveugles et décrivez toutes les étapes qui ont menées au bug
4. éventuellement un développeur requalifiera le bug pour indiquer avec précision quel paquet ou quel code source il concerne
5. un développeur “s'approprie” le bug (ou le responsable du projet le confie à un développeur), cherche et trouve une solution ou un contournement, il le marque donc “accepted as bug” le temps de ce travail
6. une fois le correctif terminé, le développeur passe le bug en “fixed”. Il faut maintenant que le mainteneur du paquet debian correspondant fasse son travail
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 (dépôt abebeta). Le mainteneur passe le bug en “awaiting response”
8. un mail d'information est envoyé sur la liste beta @ abuledu.org indiquant qu'une nouvelle version du paquet est disponible et qu'il est sensé corrigé le bug xxxx
9. 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 ?). Les testeurs commentent le bug en question sur la forge pour dire ce qu'il en est
10. si le bug n'est pas corrigé, ou que le paquet Debian introduit un autre problème, le bug passe en “won't fix” (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
11. une fois que tous les bugs concernant un même paquet sont “fixed” (donc corrigés et validés), un mainteneur Debian envoie le paquet sur le serveur APT officiel et ferme le bug (état “closed”).
12. les utilisateurs “normaux” (en production) peuvent lancer la mise à jour de leur serveur pour bénéficier de cette amélioration.