Re: [mandrivafr] [Taster] Définition du cadre

[Rémi Mathieu <imr@xxxxxxxxxxxxx>]

Le mardi 03 juin 2008, Vincent Panel a écrit :
> 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. 
>
On pourrait se limiter à:
certains paquets?
vérifier si un problème décelé sur la stable est dans la cooker? Soit en étant 
aussi un cuistot soi même, soit par le biais des annonceurs qui postent le 
bug à vérifier dans le forum cooker?
> 2) Tester les "backports"
>
+1
> 3) Tester les nouveaux kernel en développement, avant qu'ils ne
> sortent pour le grand public : les noyaux "-uc". 
+1
on peut rajouter les rt
> 4) Tester les "nouvelles choses" : 
> 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.
Il faudrait un groupe d'information ou sens large. Il y a pas mal de monde qui 
sont intéressés par relayer de l'information, et il y a un besoin de relais 
d'informations vers l'extérieur et l'intérieur.
Ca correspond à ce que tu appelles les annonceurs dans ton groupe.
Je connais au moins une dizaine de personne qui ont émis leur à intéret à 
faire ou déjà fait (vers linuxfr et quelques sites) ce genre de travail.
>
> 5) Effectuer des cas d'usages / des scénarios de test.
J'ai un cas concret qui est apparu hier. C'est intéressant parce qu'il est un 
peu à cheval sur le 1/ aussi. Il s'agit de tester un paquet, et de relayer 
des infos sur une perte de fonctionnalités due à un problème technique. Mais 
à ma connaissance, le paquet n'est dispo qu'en cooker et en testing, mais il 
fonctionne sur une 2008.1.
Je l'ai donc fait pour le dév, mais si je n'avais pas été là sur le chan à ce 
moment, il n'avait nulle part ou se tourner.

>
> 6) Tester les versions beta de Mandriva. 
le cycle commence avec alpha maintenant. :)

Mais, oui, 100 fois oui, en période de release, les groupes de tests et 
amélioration devraient se focaliser sur les versions de tests.
Il est important de comprendre que tester une rc et rapporter un bug, que ce 
soit technique ou de fonctionnalité, c'est trop tard pour les dévs. Exemple: 
le problème de raid.
L'autre point important à comprendre c'est que tester tot la mandriva en 
période de release donc avant les RC, c'est s'assurer une bonne chance que 
tout son matériel et ses logiciels chouchous fonctionnent à la release.
On perd parfois de vue qu'il y a un intérêt personnel très fort à participer à 
ce genre de tests.

> 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.
>
On peut commencer avec des tests simples (cf au dessus) qui répondent à des 
besoins importants, et on peut associer ça aux tests de facilité d'usage du 
groupe ergonomie donc mutualiser les testeurs et les ressources.



-- 
Rémi Mathieu

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