Après le résumé du développement d'Ubuntu, voici quelques outils/conseils/idées pour participer à ce développement : rapporter les bugs.

0. Pourquoi tester ?
Question bête, mais au fond pourquoi on s'embêterait à tester un système ? Voici plusieurs raisons, plus au moins intéressées.

  • Faire progresser le logiciel libre : plus il sera testé, plus il sera stable, meilleur sera le produit, et il aura plus de changes d'être accepté pour remplacer un système propriétaire. Ca c'est un peu la raison "foure-tout".
  • Participer à un projet : C'est toujours agréable de participer à quelque chose, avec d'autres gens sympathiques, de se sentir utile etc ... Ca c'est la raison pour se donner bonne conscience.
  • Découvrir : En suivant le développement, on découvre plein de choses sur son système. Exemple : comment réparer des problèmes de dépendances, recompiler un programme, repackager un programme, passer des patchs, découvrir des composants inconnus, découvrir les coulisses d'Ubuntu ... Très formateur, et très enrichissant. Ca c'est la raison pour les curieux.
  • S'assurer que son système marchera encore mieux à la prochaine version : vous avez des logiciels peu utilisés, un peu exotiques ? Vous utilisez des fonctionnalités très précises ? Vous voulez être sûr qu'après une upgrade, votre système marchera au moins aussi bien ? La meilleure façon reste de tester avant la sortie ! :) Il suffit de copier vos données personnelles, de faire tout ce que vous faites d'habitude et de rapporter les bugs que vous trouvez. Vous améliorerez le produit tout en vous assurant que la migration sera sans soucis. Ca c'est la raison égoïste :)

Toutes ses raisons sont de bonnes raisons de tester :) L'important c'est au final de le faire :)

1. Environnement de test
D'abord, il faut se créer l'environnement pour tester la nouvelle distribution. Il est important de NE PAS le faire sur son environnement normal, avec ses données. Il y a un risque très important d'altération et de perte de données. Ce n'est pas des avertissements en l'air. Pendant le développement de Feisty, cliquer sur un icône du menu effaçait complètement la partition /home (c'est à dire toutes vos données !). Alors par pitié, faites un environnement à part !

Donc quelle solution avons nous ?

  • Avoir 1 machine dédiée au test

Principe : Faire l'installation sur une autre machine que celle dont on se sert tous les jours.
Avantages : Environnement complètement séparé, accessibilité des données personnelles (sur l'autre ordi), permet de tester toutes les possibilités
Inconvénient : Disposer d'une 2e machine, Coût (électricité), devoir passer d'une machine à l'autre

  • Faire un dual-boot

Principe : Installer sur une autre partition un 2e système. C'est le même principe que le dual boot Linux/Windows, sauf qu'ici c'est Linux/Linux (voir Linux/Linux/Windows).
Avantages : On doit seulement disposer d'un peu de place sur le disque dur, permet de tester toutes les possibilités
Inconvénients : Plus d'accès à vos données personnelles (sauf à faire plein de manips), obligation de rebooter pour retrouver l'environnement stable, installation délicate

  • Virtualiser

Principe : Utiliser un logiciel de virtualisation pour lancer un autre système dans l'environnement stable. 2 exemples de logiciels : Virtualbox et VMware Server (les 2 sont gratuits, le 1e est libre).
Avantages : Environnement complètement séparé, accessibilité des données personnelles, très facile à mettre en oeuvre
Inconvénient : Ne permet pas de tester toutes les possibilités (pas d'accélération 3D), nécessite une machine pas trop ancienne.

A vous de faire votre choix. J'ai longtemps fait du dual boot, mais les nombreuses manipulations pour avoir mes données m'ont un peu énervé. Je fais maintenant de la virtualisation via Virtualbox, avec son interface très sympa et une vitesse tout à fait correcte.

Bon passons à l'installation en elle-même. 2 choix s'offre à vous :

  • soit prendre une image de test (les CD alpha) et faire une installation normale.
  • soit prendre la version stable, changer les noms de version (feisty par gutsy par exemple) dans le fichier /etc/apt/sources.list et faire un sudo apt-get update & sudo apt-get dist-upgrade

Après, il faut personnaliser un peu cet environnement pour simuler l'utilisation personnelle que vous aller faire. Quelques exemples :

  • Vous pouvez copier les fichiers de configuration de certains programmes que vous utilisez couramment (mail, navigateur ...), de quoi mettre un peu à l'épreuve ce système. Pour cela, affichez les fichiers cachés dans votre répertoire /home (Contrôle + H dans Nautilus). Vous allez voir des répertoires .evolution, .gaim etc ... C'est ces répertoires qu'il faut copier dans votre environnement de test, dans le /home.
  • Pour la messagerie, configurez vos adresses mails pour que vos mails soient téléchargées mais restent sur le serveur. Ca permet de tester la gestion des mails en gardant une copie de sauvegarde sur le serveur (qui seront eux téléchargés par votre système stable ;)).
  • Récupérez quelques fichiers musicaux et vidéos pour tester tous les codecs.
  • Récupérez quelques fichiers au format open document, .doc pour tester les logiciels de bureautique, ou tout autre programme de travail (compta, projets ...)

Gardez bien à l'esprit que tout ce que vous faites dans votre environnement de test peut être perdu à tout moment.

Enfin, pour aller plus loin, vous pouvez ajouter cette ligne à votre source liste : deb http://people.ubuntu.com/~pitti/ddebs gutsy main universe (à adapter selon la version) puis cette clé wget -q "http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x0DE7276D5E0577F2" -O- | sudo apt-key add -
Cela va vous fournir des paquets du type *-dbgsym qui donnent plus d'infos pour les développeurs. Par exemple, si evolution plante (cad se ferme de façon inopinée) faites un sudo apt-get install evolution-dbgsym , puis refaites planter evolution et envoyez le rapport de bug. Toutefois attention, ces paquets ne sont pas tout à fait synchronisés avec les paquets "normaux", donc ils peuvent générer des conflits de paquets. Pensez à les désinstaller quand vous n'en avez plus besoin :)

2. Présentation de Malone
En tant que béta-testeur, Malone, le bugtracker d'Ubuntu, va devenir votre 2e maison. Commencez par vous inscrire, et modifiez un peu vos paramètres pour personnaliser tout çà. Ah oui, si l'anglais n'est pas votre fort, prenez un dico car tout est en anglais :p. Sur votre page, vous avez accès à toutes vos participations. On va se concentrer sur l'onglet "bugs" avec sur la gauche la liste des bugs que vous avez reportés, ceux auxquels vous êtes abonnés etc ... Les bugs sont classés par paquets, c'est à dire que si vous voulez tous les bugs d'un paquet, il faut entrer l'adresse https://bugs.launchpad.net/ubuntu/+source/lenomdupaquet/+bugs (en changeant lenomdupaquet par le paquet que vous voulez ;)). Vous allez devoir aussi apprendre les noms des paquets :)

3. Commençons les tests et comment identifier les bugs
La chasse aux bugs peut commencer. Vous pouvez maintenant faire toutes les actions que vous voulez pour mettre à mal le système. Quand vous rencontrez une anomalie (une fonction qui ne marche pas, un comportement inhabituel), un bug (crash de programme, impossibilité de lancer un programme), vous aller pouvoir commencer à travailler. Assurez vous d'abord que le bug est reproductible (ce qui garantie que c'est un vrai bug). Ensuite, cherchez dans Malone si le bug n'existe pas. C'est important car rapporter 10 fois le même bug ne sert à rien. Cela oblige même les gens a trier ces bugs et de les marquer comme "dupliqués". Faites une recherche par le nom du paquet (cf 2.). Si le bug est déjà présent, laissez un commentaire sur le rapport de bug en disant que le bug est aussi présent chez vous, en ajoutant des détails si celui qui a rapporté le bug n'en a pas mis beaucoup. Il peut être intéressant de faire des recherches dans les forums, pour voir si le problème a été remarqué mais non rapporté. Si le bug n'existe pas, et que vous êtes sûr du nom du paquet, vous pouvez créer un nouveau rapport de bug avec votre version d'Ubuntu (bien préciser que vous êtes en version de test), comment reproduire le bug (très important), les paquets installés qui sont relatifs aux bugs etc ... Evidemment, tout ça doit être en anglais :) Inspirez vous de certains rapports déjà faits et passez Firefox en correction orthographique anglaise pour vous aider :)

Sur Ubuntu, il existe un programme qui compile toutes les infos lors d'un crash logiciel : apport. S'il ne se lance pas tout seul pour rapporter le bug, vous pouvez manuellement récupérer le fichier dans /var/crash , et le fichier devrait porter le nom du programme qui a planté. Limitation : cela ne fonctionne que pour les programmes qui crashent. Ce fichier + la façon de reproduire le bug peut suffire aux développeurs pour corriger le bug.

Pensez à vous abonner aux rapports de bugs qui vous intéressent pour être informé automatiquement par mails de l'avancement de leurs résolutions. Ca permet de suivre plus facilement.

A noter pour finir, qu'il ne sert à rien de rapporter les bugs dans les premières semaines de tests. Les changements sont tellement fréquents que le bug peut disparaître très rapidement, sans action nécessaire. Vous pouvez commencer la chasse quand le 1e CD alpha est sorti, de quoi avoir une bonne base de départ.

4 Suivre et trier
Il est important de suivre les bugs qu'on rapporte, sinon ils risquent de rester et de s'accumuler dans le bugtracker. Il ne sert a rien de relancer les développeurs, mais s'ils vous demandent + d'infos, il faut penser à les fournir. Plus vous serez réactifs, plus le développeur se focalisera sur ce bug et plus rapidement il pourra être corrigé. Un bug qui traine a de moins en moins de chances d'être résolus.

Penser aussi à suivre les nouveaux paquets qui arrivent, soit en vous abonnant à la liste des changements (https://lists.ubuntu.com/archives/gutsy-changes/ pour gutsy, à changer selon la version), soit en faisant régulièrement les mises à jour. Les mises à jour de paquets peuvent corriger certains bugs.

Quand un bug est corrigé, pensez à le noter comme tel dans le bugtracker (Status "Fix release"). Ca fait toujours plaisir.

Si vous vous sentez le courage, vous pouvez essayer de trier les bugs. Cela consiste notamment à repérer les bugs reportés en double (et marquer le plus récent en « dupliqué »), assigner des noms de paquets à des rapports qui n'en mentionnent pas, demander + d'infos si le rapport est incomplet etc ... C'est aussi une partie importante car sans ordre, le bugtracker peut vite devenir illisible.

5. Participer en groupe
Si vous voulez participer en groupe à ces corrections, vous pouvez rejoindre la BugSquad (l'équipe spécialisée dans la chasse aux bugs), ou participer aux Hug Days, ces journées consacrées à la chasse aux bugs.

Voilà de quoi bien commencer à chasser les bugs. Après, il faudra vous forger votre propre expérience pour vous améliorer. Mais tout est question de motivation et de patience :)