[mandrivafr] [Taster] Définition du cadre

["Vincent Panel" <yohonet@xxxxxxxxx>]

Salut !

Le projet taster se définit peu à peu et possède maintenant un roadmap
: http://www.mandrivafr.org/trac/taster/roadmap et des tickets à
résoudre avant de pouvoir progresser :
http://www.mandrivafr.org/trac/taster/report/1

Dans l'état actuel, le cadre du projet reste à définir (de façon
sereine et constructive :-) ). Voilà les différentes choses qui
peuvent être "testées" : rentrent-elles dans le cadre du projet ?
c'est la chose que je voudrais discuter ici. Je donnerais mon avis à
la fin.

1) Tester la distribution cooker. Avantage par rapport à la ML cooker
: ce sera en français. Inconvénients : il existe déjà le forum cooker,
ça ne sert à rien de dupliquer les efforts. Le but originel du forum
cooker était d'avoir une sorte de bugzilla, avec des règles strictes
mais en français avec l'interface du forum. Il est dorénavant devenu
plutôt un forum de discussion autour de cooker.

2) Tester les "backports" : ce sont des paquets issus de cooker, mais
qui s'installent sur la dernière version stable de Mandriva (voir le
wiki pour plus de précisions).

3) Tester les nouveaux kernel en développement, avant qu'ils ne
sortent pour le grand public : les noyaux "-uc". Ces kernels sortaient
régulièrement pour la 2007 Spring et 2008, mais je ne sais pas s'ils
sont toujours d'actualité pour la 2008 Spring, je vais me renseigner.

4) Tester les "nouvelles choses" : environ 1 fois par trimestre, une
personne a une idée de génie et décide de publier un nouveau paquet
avec cette nouvelle fonctionalité, utilisable sur la version stable
(exemple : un live CD Xfce ou un nouveau kernel capable de lire les
blu-ray). Il n'existe actuellement pas de mailing list ou de forum
pour diffuser une telle nouvelle, de même qu'il n'existe pas
réellement de communauté pour tester derrière. Ça freine ce genre
d'initiative car si on diffuse la nouvelle sur la liste cooker, peu de
gens ont la version stable (c'est pourtant le moyen utilisé
actuellement...).

5) Effectuer des cas d'usages / des scénarios de test. C'est ce qui a
déjà été fait dans le passé avec "testzilla" : il s'agit d'une
procédure qui décrit étape par étape comment effectuer une certaine
action (par exemple, graver un DVD de Mandriva Linux avec K3B). Le
testeur suit cette procédure et lors d'un rapport final indique s'il y
a eu un problème pour faire l'action. Chaque problème donnera lieu à
une discussion, puis éventuellement à la création d'un rapport de bug
dans bugzilla.

6) Tester les versions beta de Mandriva. Oui, l'arrivée des versions
béta sont largement relayées, mais qu'en est-il des retours
d'installation ? Au final, on s'aperçoit que peu de gens utilisent
bugzilla pour rapporter CHAQUE problème rencontré (ce qui est la
méthode recommandée). Les principales raisons sont : l'anglophobie, la
bugzillophobie ou tout simplement faire un rapport sous forme écrite
est bien plus facile. Il manque donc un maillon entre bugzilla et les
testeurs. D'autre part, les tests ne sont pas "organisés" : on ne sait
pas combien de testeurs testeront la version beta1, la beta2, la rc1
et la rc2. Si bien, qu'on se retrouve souvent avec des frustrations :
les testeurs de la RC2 se retrouvent avec pleins de bugs car les
versions précédentes n'ont pas été testées par suffisament de monde.
Les developpeurs, eux, ne comprennent pas qu'on leur parle de
problèmes si tard dans le cycle de développement.

À l'origine, j'avais envisagé le projet taster pour faire les tests 2,
3, 4 et 6.

Le type 1 me semble hors du cadre du projet : pour moi, les tests
s'adressent à la majorité des utilisateurs, donc ceux qui utilisent la
version stable.

Je suis assez méfiant sur le type 5 car l'échec de testzilla a montré
qu'une structure trop formelle fait fuir pas mal de monde et tant que
l'on ne dispose pas d'un nombre de testeurs (disponibles : qui ont du
temps...) suffisant, c'est un peu cause perdue.

Voilà, j'attend vos avis !

---
http://magnum.tuxfamily.org - http://wiki.mandriva.com/fr/Association_des_utilisateurs_de_Mandriva