De Wiki de la communauté Mandriva.

Sommaire

1 Comment participer au projet Mandriva Cooker
2 References

Comment participer au projet Mandriva Cooker

2008.0 développements en cours

Mandriva GNU/Linux 2007.1 est la version stable actuelle de Mandriva GNU/Linux. La Cooker (future 2008.0) est en développement actif pour la prochaine release.

Background

L'un des problèmes majeurs dans le processus de dévelopement de Mandriva GNU/Linux est que la période de beta testing est trop courte et ne permet pas aux utilisateurs de s'y investir avant la version suivante.

Après de nombreuses discussions concernant ce problème sur la mailing-liste cooker, il est vite devenu évident qu'il y a un manque de compréhension de la part de la communauté du processus de développement de Cooker.

La vérité en la matière est que la période de beta test de Mandriva GNU/Linux dure environ 3 mois, mais la majorité des utilisateurs ne s'y investit qu'à la fin du processus, et a donc l'impression que la période de beta-test est trop courte.

Le but de ce document est de donner aux utilisateurs intéressés les informations nécessaires pour pouvoir s'investir au plus tôt dans la phase de test de la prochaine version de Mandriva GNU/Linux. Ceci permettra plus de retours de la part des utilisateurs vers les développeurs.

Invariablement les utilisateurs installent la 2ème release candidate, et postent alors de très nombreux messages sur la mailing-liste Cooker et le bugzilla, exigeant (ou demandant) de nouvelles fonctionnalités pour cette version.

Malheureusement, rendu a ce point du développement, il est bien trop tard pour décider d'ajouter des fonctionnalités ou de nouvelles applications à la distribution. Si ceci vous correspond, alors les informations dans ce document vous seront d'une grande aide.

Ce qu'est Cooker

La version de développement de la prochaine version de Mandriva GNU/Linux est nommée Cooker.

Le but de Cooker est d'améliorer la distribution Mandriva GNU/Linux en permettant une meilleure interaction entre l'équipe de développement et les utilisateurs de Mandriva GNU/Linux, tant pour la chasse aux bogues que pour participer aux réflexions sur les nouvelles fonctionnalités.

C'est une distribution complète, qui est en changement permanent, et qui parfois ne peut même pas être installée car certains composants sont cassés ou incompatibles entre eux.

Attention : Le terme Cooker est utilisé pour :

La mailing-liste Cooker (discussions concernant Cooker)
La distribution Cooker (que vous pouvez installer et utiliser)
Le repository Cooker qui contient les paquetages RPM.
La "Cooker way of life", utiliser une distribution toujours "cutting Edge", sur le fil du rasoir des nouvelles technologies ;)

Ce que Cooker n'est pas

Cooker n'est pas l'endroit où récupérer la dernière version d'un programme pour votre distribution Mandriva GNU/Linux stable. N'installez jamais un paquet cooker sur une distribution stable ; les RPMs Cooker sont incompatibles car ils sont compilés avec des librairies qui ne sont pas disponibles sur votre version stable. De plus, de nombreux paquets peuvent être bogués car étant en version de développement.

Les manières de participer

Il y a de nombreuses manières de participer au projet Cooker. La manière la plus commune est d'installer une des images ISO pendant le cycle de versions beta, mais vous pouvez aussi contribuer aux logiciels ou en apportant des idées.

Remarques

Premièrement, vous devez vous rappeler que Cooker est une distribution de développement, qui n'est pas encore très testée et qui peut corrompre des données ou des configurations, etc. Cette distribution n'est pas faite pour être mise en environnement de production. vous aurez été prévenus

Un exemple typique de cas où la migration vers Cooker signifie une perte de configuration sont les updates kernel, dans ce cas vous avez à reconstruire tous les drivers externes (Third party drivers).

La plupart des bugs INVALIDES rapportés par les utilisateurs concernent des cartes graphiques (NVIDIA surtout) ; le kernel grandit vite et ses interfaces changent souvent, et parfois il n'est pas possible de reconstruire un module propriétaire qui devra s'adapter au nouveau kernel.

Cependant, la distribution étant en phase de développement, vous pouvez demander des patchs aux développeurs de ces modules propriétaires externes.

Cependant utiliser Cooker est aussi intéressant, car vous êtes le premier à voir les nouvelles améliorations, les nouveaux programmes ajoutés à la distribution Mandriva GNU/Linux. Si vous participez sur la mailing-liste cooker ou le bugzilla, vous influencerez réellement la développement de la prochaine version de Mandriva GNU/Linux.

Installer Cooker

Le premier pas pour participer à Cooker, est bien sûr de l'installer ; comme pour toute autre distribution GNU/Linux, il est possible de l'installer de plusieurs manières.

par FTP à partir d'un miroir public

Faites une disquette de boot avec le fichier network.img qui se trouve sur tout miroir Cooker. Ce fichier devrait se trouver dans le répertoire cooker/i586/images/ de l'arborescence mandriva-devel sur le miroir. Si vous utilisez déjà Linux vous pouvez utiliser dd pour copier ce fichier sur une disquette.

     dd if=network.img of=/dev/fd0

Si vous n'utilisez pas encore Linux, vous pouvez utiliser l'utilitaire rawwrite pour créer la disquette de démarrage sous DOS ou Windows. Cet utilitaire se trouve normalement dans le répertoire /cooker/i586/dosutils de l'arborescence mandriva-devel sur le miroir.

Si votre système n'a pas de lecteur de disquettes, comme c'est hélas de plus en plus souvent le cas, vous pouvez graver une image (network.img, pcmcia.img, au choix) sur un CD-ROM bootable.

     mkdir image
     cp network.img image
     mkisofs -b network.img image > network.iso
     cdrecord dev=0,0,0 network.iso
     rm -fr image

Installer à partir d'une image ISO

Des images ISO (versions ISO gravables sur CD-ROM) sont des snapshots de cooker qui sont disponibles environ 3 mois avant que Cooker ne soit considérée stable et devienne la prochaine version officielle. La première version est généralement nommée Snapshot Cooker . Si vous suivez la "version Snapshot Cooker", environ toutes les 2 semaines, un nouveau jeu d'images iso sera créé et distribué pour être testé avant la sortie de la prochaine version officielle. Les prévisions de sortie pour les prochaines versions trouvent ici. Beaucoup de gens apprécient d'installer et de tester ces images ISO. Cependant si vous testez a partir d'une de ces images ISO de Cooker, faites particulièrement bien attention à utiliser la toute dernière qui est sortie.

Sachez qu'il est aussi possible d'avoir une "Release Candidate" supplémentaire ( RC3 ) si le travail restant le nécessite ; 9.1 et 9.2 ont eu 2 versions candidates et la 9.0 en a nécessité 3.

Vous pouvez trouver ces images ISO sur la plupart des miroirs mandriva-linux, ou vous pouvez les télécharger en utilisant Bittorrent. Jetez un oeil sur La page principale pour trouver un lien vers les fichiers Bittorrent officiels et les instructions pour les télécharger. Si vous avez des problèmes avec Bittorrent, regardez La FAQ Bittorrent sur le site mandrivaClub .

Garder vos ISO à jour sans tout re-télécharger à nouveau

Lorsque vous testez des images ISO de snapshots Cooker, vous devrez télécharger une nouvelle ISO toutes les 2 semaines. Si votre connexion n'est pas suffisament rapide, vous pouvez réduire considérablement la quantité de bande passante nécessaire en synchronisant vos images ISO avec rsync. Voici un lien vers un article qui sera plus tard intégré dans cette page et qui explique comment Utiliser rsync pour mettre a jour des images ISO Mandriva Linux

Installer à partir d'un miroir local

Si vous avez plus de 6 Giga d'espace disque disponible, il est assez rapide et facile d'installer à partir d'un miroir local se trouvant sur votre disque dur ou sur un serveur de votre réseau local. Il y a même des scripts disponibles pour créer un jeu d'images ISO à graver sur CD à partir de ce miroir pour installer de manière traditionnelle. Utilisez fmirror ou rsync pour créer un miroir local et le maintenir à jour avec les miroirs de référence.

(il serait bon d'ajouter ici quelques pointeurs et informations sur l'utilisation de rsync)

Pour installer l'utilitaire "rpmsync" pour cooker:

urpmi rpmsync

Lancer gendistrib

Si vous mettez en place un miroir local, il peut arriver que les fichiers hdlists soient désynchonisés, il est donc bon de lancer un script nommé gendistrib avant de mettre à jour vos sources urpmi. Pour lancer le script, vous devez avoir des droits d'écriture sur l'arborescence qui contient la distribution (votre miroir). Placez-vous dans le répertoire qui contient la racine de votre "dist tree" et tapez :

     gendistrib --distrib

Par NFS ou sur un réseau local

Utilisez l'image network.img pour créer une disquette de boot en utilisant une des méthodes décrites ci-dessus et sélectionnez NFS au lieu de ftp

A partir d'un miroir local sur un disque dur local

Si votre miroir local se trouve sur une partition de la même machine sur laquelle vous comptez installer Cooker, utilisez l'image hd_grub.img pour créer une disquette de démarrage utilisant l'une des méthodes décrites ci-dessus (elle se trouve dans le répertoire install/images du miroir). Vous pouvez ensuite suivre les instructions de [[1]] pour créer un menu grub.

Par le disque dur ou le reseau sans disquette ni cdrom

De nos jours de nombreuses machines n'ont pas de lecteur de disquettes ou de lecteur de cdrom.

Nous avons une solution pour cela aussi.

Copiez les fichiers nécessaires à partir du répertoire isolinux vers /boot/

     cd /path/to/mirror/isolinux/alt0/
     cp vmlinuz /boot/vmlinuz-all
     cp all.rdz /boot

Créez une entrée dans le fichier /etc/lilo.conf sivous utilisez LILO ou dans /boot/grub/menu.lst si vous utilisez GrUB

Example pour lilo

     image=/boot/vmlinuz-all
          label=all-install
          root=/dev/ram3
          initrd=/boot/all.rdz
          append="ramdisk_size=32000"
          vga=791
          read-only

Notez qu'à partir de la Mandrakelinux 10.1beta2 vous devez augmenter la valeur du parametre ramdisk_size pour installer à partir du disque dur. Pour être certain d'avoir de la marge, vous pouvez le paramétrer à 700000. Comme toujours, après avoir fini d'éditer /etc/lilo.conf, vous devez relancer lilo avec la comande :

 /sbin/lilo -v

pour que vos changements soient pris en compte au prochain redémarrage.

Exemple de paramétrage pour le chargeur de boot (bootloader) grub

     title all-install
     kernel (hd0,0)/boot/vmlinuz-all root=/dev/ram3 ramdisk_size=32000 vga=791
     initrd (hd0,0)/boot/all.rdz

Installer à partir du disque dur (en utilisant des images iso)

L'installation à partir du disque dur peut aussi utiliser des images ISO locales (il est nécessaire de mettre toutes les images ISO dans le même répertoire). Il y a plusieurs manières d'utiliser ces images ISO :

vous pouvez récupérer l'image install/images/boot.iso à partir d'un miroir, le graver sur un cd et démarrer avec,
vous pouvez copier le répertoire install/isolinux/ à partir d'un miroir sur le disque dur local, puis utiliser [[2]] pour créer une disquette de boot grub (voir Via Hard Disk Install)
si vous avez déjà un système GNU/Linux, vous pouvez ajouter une entrée dans la configution de votre chargeur de démarrage (bootloaders lilo ou grub ).

Pour monter les images ISO dans un répertoire, utilisez, en root, la commande suivante :

     mount -t iso9660 mandrakelinux-10.0-CD1.i586.iso /mnt/iso/ -o loop

(voir aussi Via Hard Disk or Network with No Floppy or CD-ROM)

Une fois que l'installeur est lancé, il demandera où se trouvent les images ISO, sur quel disque dur, quelle partition et quel répertoire. Si le répertoire spécifié contient plus d'une image ISO, l'installateur demande laquelle doit être utilisée.

Créer des CDs avec la commande MakeCD

MakeCD est un script qui lance mkcd, il va créer un jeu d'images ISO que vous pourrez graver sur des CDs. Si vous disposez d'un miroir Cooker local, il est très facile de créer votre jeu d'images ISO.

Si les disquettes de boot ne contiennent pas vos drivers

Deux problèmes majeurs (peut-être plus ;-) ) peuvent survenir :

Premièrement, si vous avez un adapteur SCSI très ancien, nous n'incluons peut-être plus le driver correspondant dans les disquettes de boot, donc si vous ne pouvez booter votre CDROM (les anciens BIOS SCSI n'offrent pas de capacité de boot), vous êtes piégé.

Deuxièmement, si vous avez besoin d'un driver propriétaire (nvnet.o par exemple).

Ces problèmes peuvent être résolus de la façon suivante :

Créez une disquette de démarrage traditionnelle (cdrom.img pour le cdrom, network.img pour le réseau...)
Créez aussi une disquette ext2 avec la commande :

     mke2fs /dev/fd0

Trouvez votre driver et copiez-le (non compressé) sur la disquette ext2 avec la commande suivante (ou son équivalent pour un autre driver) :

     zcat /lib/modules/<kernel-version>BOOT/kernel/3rdparty/dc395x_trm/dc395x_trm.o.gz \
         > /mnt/floppy/dc395x_trm.o

Copiez aussi les dépendances de ce module (non compressées elles-aussi), comme par exemple scsi_mod.o ; il peut y avoir d'autres dépendances, vérifiez dans le fichier modules.dep.

Démarrez avec la première disquette de démarrage traditionnelle et tapez F1 puis tapez:

linux expert ceci vous permettra, un peu plus tard, d'insérer l'autre disquette pour ajouter vos drivers, par ordre de dépendances bien sûr (par exemple scsi_mod.o en premier...)

Installer à partir d'une clef USB

Depuis le 27/01/2005 (après la 10.2 beta2 non incluse), une nouvelle image est disponible pour démarrer sur une clé USB. Le fichier <vervatim>all.img</verbatim> est une image fat16 sur laquelle vous pouvez utiliser dd pour la mettre sur une partition (par exemple, sda1 pour la plupart des clés USB).

Problèmes possibles :

Il semblerait que certains BIOS n'utilisent pas le code du MBR (Master Boot Record) (sda), ou au moins l'ignorent quand il est vide :

dd if=/dev/zero of=/dev/sda bs=1 count=446"

Certains BIOS ont besoin de ce MBR. Pixel a réussi a trouver un moyen de les utiliser en installant le paquet extipl et avec :

dd if=/usr/lib/extipl/aldebaran.bin of=/dev/sda

Avec un boot PXE

Ceci est probablement l'une des manières les plus faciles pour un admin. Vous devez avoir une carte réseau récente (PXE1.5 ou supérieure) ; PXE <= 1 peut etre utilisé mais cela crée des problèmes avec certaines cartes.

Installez un serveur PXE, Mandriva GNU/Linux dispose de paquets pour cela, mais sauvegardez votre fichier dhcp.conf. Dans le fichier par défaut, pxelinux.cfg/default, ajoutez la ligne:

label 10-1-OE
        KERNEL vmlinuz
        APPEND initrd=all.rdz ramdisk_size=128000 acpi=ht vga=788

et ajoutez le vmlinuz et all.rdz dans votre serveur tftp

Conserver votre installation Cooker à jour

(ndlt: fast tip : <verbatim>urpmi.update -a && urpmi --auto --auto-select</verbatim> )

URPMI est votre ami

Définir des sources urpmi Cooker

Un des outils les plus utiles, développé par la distribution Mandriva GNU/Linux, est le script easyurpmi d'Oliver Thauvin. Ce script peut être trouvé sur : http://easyurpmi.zarb.org

Vous pouvez aussi utiliser une interface graphique :

urpmi.setup

Installez le paquet urpmi.setup, et lancez-le. Il va chercher les listes de miroirs disponibles sur internet et vous permet alors de choisir les sources urpmi que vous souhaitez ajouter Pour économiser la bande passante utilisée, vous pouvez utiliser un miroir utilisant rsync (dont l'url commence par rsync://).

Sivous avez un miroir préféré qui ne se trouve pas dans la liste du script easyurpmi ou si vous disposez d'un miroir local, vous pouvez créer la ligne de commande vous-même avec la syntaxe suivante :

     urpmi.addmedia <name> <source> with <relative path to hdlist>

Vous pouvez trouver une liste complète des miroirs à jour et cassés sur : [[3]]

Lorsque vos sources urpmi sont configurées pour Cooker, vous pouvez les mettre à jour en lancant la commande : urpmi.update

en spécifiant une source à mettre à jour :

     urpmi.update <source urpmi à mettre à jour>

si vous avez plusieurs "repository"

En Cooker toutes les sources changent à peu près tous les jours, et il est plus facile de mettre à jour toutes les sources urpmi avec la commande :

     urpmi.update -a

Ceci mettra à jour le fichier de configuration pour toutes les sources avec les derniers fichiers hdlist.cz disponibles. Si vous ne lancez pas cette commande, urpmi ne connaîtra pas les dernières mises à jour, et continuera à répondre que tout est déjà installé, même si de nouvelles versions sont disponibles sur les miroirs.

Lorsque vos sources urpmi ont ainsi été mises à jour, lancez :

     urpmi --auto-select

pour mettre à jour tous les paquetages déjà installés sur votre machine.

urpmi va vérifier, pour chaque paquet déjà installé, si une nouvelle version est disponible sur l'un des miroirs. Si une nouvelle version du paquet existe, elle sera installée avec toutes les dépendances nécessaires.

A partir de sa version 4.4, urpmi supporte les transactions ; ceci signifie que les paquets peuvent être téléchargés et installés par groupes de paquets liés qui s'installent en même temps. Ceci évite des problèmes lorsque votre partition /var est petite ou dispose de peu d'espace disque disponible. De même, depuis la version 4.4-41mdk, urpmi se met à jour lui-même avant de mettre à jour tout autre paquet le nécessitant (plus besoin de lancer urpmi urpmi).

Vous pouvez utiliser les flags --auto et --no-uninstall ( à partir d'une version > 4.3-13mdk ) (ndlt : et --auto-select aussi non ? ) pour une mise à jour complètement automatisée. Rien ne sera désinstallé et aucune question ne sera posée.

Les sources du kernel sont automatiquement mises à jour mais pour mettre à jour le kernel lui-même vous devrez aussi lancer :

     urpmi kernel
     urpmi kernel-secure
     urpmi kernel-xxxxxxx

Ceci est nécessaire car de nombreux kernels sont disponibles et un ancien kernel n'est jamais désinstallé lorsque vous en installez un nouveau. Vous devez donc spécifier le type de kernel à mettre à jour, par exemple kernel ou kernel-secure.

Le dernier pas est de mettre à jour la configuration. Pendant les mises à jour, des fichiers .rpmnew peuvent avoir été créés (vous êtes prévenus de leur création mais il est facile de les rater) Lancer etc-update peut vous aider à mettre à jour ces fichiers de configuration.

Comment bien signaler un Bug

Si vous pensez avoir trouvé un bug, il y a certains points à respecter avant de le remonter sur la base de données bugzilla :

Premièrement, soyez certain que vous êtes à jour pour tous les paquets Cooker en relation avec le problème ; après avoir mis à jour tous ces paquets vous verrez si le problème persiste, sinon le bug a déjà été corrigé par les mises à jour.

Cooker change chaque jour, donc si vous pensez avoir trouvé un bug dans une beta2, qui date de plus d'une semaine, il y a de grandes chances pour que le paquet ait déjà été mis à jour plusieurs fois depuis la sortie de votre version sur CDs. Vous devez donc mettre à jour vos paquets en mettant à jour vos sources urpmi puis en mettant à jour au moins les paquets concernés voire même tout votre système (avec urpmi.update -a && urpmi --auto-select : voir conseils d'utilisation de urpmi ci-dessus)

Deuxièmement, soyez certain que ce problème est reproductible ; en effet, les développeurs penseront souvent qu'un problème reproductible est un probleme de configuration, donc si vous pouvez reproduire le problème sur une autre machine ou un autre compte, cela rendra votre "bug report" beaucoup plus utile et mieux pris en compte.

Troisièmement, en cherchant sur la mailing liste Cooker, vous pourrez trouver des problèmes similaires ou des discussions sur ce problème précis. Si le problème a déjà été remonté, vous pouvez ajouter des informations au rapport de bug existant. Cela n'a aucun sens de créer une nouvelle entrée dans la base de données pour un problème déjà existant et déjà signalé.

Faites bien la différence entre la mailing liste Cooker et le bugzilla ; utilisez la mailing liste Cooker (et l'IRC ? ndt) pour discuter et savoir si un problème est un bug ou pas, utilisez le bugzilla pour signaler le bug une fois qu'il est clairement identifié.

Un bon rapport de bug nécessite d'être précis dans sa description, il n'est en aucun cas suffisant de dire "le paquet XXX est cassé" sans préciser une description claire du problème. Donnez au moins le nom du paquet concerné ainsi que sa version (avec rpm -qa | grep nom_du_paquet) ainsi que la description du problème, de ses effets et messages d'erreur éventuels. Donnez les informations concernant votre machine et tout détail de votre environnement qui pourrait donner des indices et aider a comprendre le problème sur d'autres machines ; même les fichiers de configuration des paquetages concernés peuvent être utiles.

Comment utiliser le bugzilla

Le bugzilla est le logiciel qui gère la base de données qui contient les bugs. Pour soumettre un bon rapport de bug, vous devez créer un compte bugzilla valide, ce qui est très facile en allant sur : [[4]] et en cliquant sur le lien "Open a new Bugzilla account" : saisissez les informations nécessaires.

Les comptes standards peuvent ajouter de nouveaux bugs et changer le statut des bugs qu'ils ont signalés eux-mêmes.

Avant de valider un nouveau rapport de bogue, bugzilla va chercher dans la base de données des bogs similaires et vous les proposer pour savoir si vous êtes sur de vouloir proposer un nouveau bug.

Comment bugzilla fonctionne

L'interface web est la manière la plus utilisée pour bugzilla; le bugzilla de Mandriva se trouve sur [[5]]

Il y a aussi une interface mail pour bugzilla qui rends rapide et facile d'ajouter des commentaires ou de changer le statut de vos rapports lorsque vous en avez les droits. (ndt: ajouter url pour l'interface mail ?)

La signification des différents statuts de bugs

Ces statuts définissent l'état du rapport de bogue:

UNCONFIRMED - Ce rapport est nouveau et personne (ni développeur, ni autre utilisateur) n'a confirmé le problème ; tant que personne ne l'aura confirmé, ce bogue restera "unconfirmed".
NEW - Ce bogue est nouveau
NEEDINFO - Un développeur a demandé plus d'informations concernant ce rapport de bogue
FIXED - Ce bogue est réputé corrigé
INVALID - Ce bogue a été classé comme inexistant et ignoré
WONTFIX - Pour quelque raison que ce soit, dont on peut espérer qu'elle sera expliquée dans les commentaires, ce bogue ne sera pas (ou ne pourra pas) être corrigé (car considéré comme sans importance ou impossible à corriger).
LATER - Ce bogue est reconnu comme existant, mais ne pourra être corrigé que plus tard
REMIND -
WORKSFORME - Personne n'a pu reproduire le problème, le comportement reste normal, impossible donc de gérer ce problème
OLD - Ce bogue n'a plus lieu d'être car il a déjà été corrigé ou que le paquet a été retiré de la distribution.

Voter pour des bugs ?

Bugzilla fournit un système de vote pour aider les utilisateurs à valider des rapports de bogue. Ce système doit être utilisé par des utilisateurs qui ont pu reproduire un problème signalé par un autre utilisateur et qu'ils confirment l'importance de corriger ce problème, plutôt que de créer un autre rapport de bogue pour le même problême ou un problême lié.

La mailing liste Cooker

La mailing liste Cooker a un très grand trafic de mails (entre plusieurs centaines et mille mails par jour ;-) ; il est donc très important de faire attention où et comment vous postez sur cette liste. Il est nécessaire de réduire le bruit et de vérifier si des messages ont déjà été postés concernant le sujet pour y répondre plutôt que de créer un nouveau thread. Il est possible de chercher dans les archives de la mailing liste sur : [[6]] et [[7]] Pour augmenter les chances que vos messages soient lus, aidez à minimiser le bruit, la pollution, les messages inutiles ou déplacés... Pas de messages sans rapport avec la distribution et son développement SVP.

La Mailing List est l'endroit par excellence où se discutent la façon d'implémenter des fonctionnalités, des paquets ou pour discuter si un comportement est un bogue ou pas. Les rapports de bogues eux-mêmes se trouvent dans le bugzilla.

Si vous ne pouvez pas suivre Cooker mais que vous souhaitez tout de même rester au courant des discussions, vous pouvez regarder les CookerWeeklyNews. ( ndt: ajouter l'url de ces CookerWeeklyNews ? ).

Cependant si vous utilisez Cooker, cherchez au moins dans les archives lorsque vous avez un problème ([[8]])

TestzillaHowto

Les pages Testzilla sur (latest results, hardware statistics, autres liens sur la page principale de Bugzilla ), suivez les procédures pour signaler des succes ou des problemes concernant les rapports de bugzilla que vous testerez.

Pour pouvoir tester le hardware, vous devez d'abord uploader votre configuration système pour que bugzilla connaisse votre matériel. Pour le faire, installez le paquet hwdb-clients et lancez hwdb_add_system <bugzilla account> "<system name>". Votre profil apparaîtra alors sur la page My Hardware , et vous aurez accès aux nombreuses procédures de validation hardware proposées sur La section Testzilla du Bugzilla.

Consultez le wiki du TestzillaHowto si vous souhaitez contribuer aux procédures ou voir comment le système fonctionne.

Contribuer en proposant des patchs

Si vous écrivez un patch pour régler un problème dans l'un des outils développés par Mandriva, envoyez votre patch sur la mailing liste Cooker et au mainteneur du paquetage concerné.

Si vous écrivez un patch pour un programme qui est maintenu en paquetage mandriva, envoyez votre patch au mainteneur de ce paquet Mandriva, mais aussi à ce que l'on appelle l'"upstream" (en amont), le responsable du programme lui-même, développé indépendemment de la distribution Mandriva Linux.

Les mainteneurs de paquet Mandriva patchent souvent les sources des programmes pour des bugs majeurs, mais les sources eux-mêmes doivent être corrigés dans le projet externe à Mandriva. Tous les projets n'ont pas d'employés Mandriva qui travaillent dans leur CVS, vous devez donc soumettre vos patchs au projet lui-même, le patch adressé à Mandriva n'étant pas nécessairement répercuté en amont sur le cvs du projet.

Glossaire des termes utilisés ici

Alpha Release - Version alpha -

Aussi appelée Cooker snapshot. Il est probable que vous trouverez des bogues dans cette version. Elle est probablement cassée (et sûrement bien cassée) mais ce serait bien que vous la testiez dans l'ensemble (plutôt que d'en tester des parties). Les développeurs sont motivés à effectuer de grands changements (montée de versions, ...) pour faire tout marcher au mieux, c'est donc le moment de faire savoir que votre paquet préféré ou vos fonctionnalités tant attendues doivent être pris en compte.

Beta Release - une beta est une version ISO de Cooker permettant de tester les nouvelles fonctionnalités ou celles en cours de développement pour certains composants de la distribution. Il y a probablement des bogues gênants ou bloquants, vous ne voudrez pas l'utiliser en production, mais essayez-là à des fins de tests pour des tâches sans trop d'importance. A ce moment, les mainteneurs de paquets n'ont pas vraiment envie de monter de version hormis pour régler des problèmes. Les problèmes mineurs qui réclameraient beaucoup d'effort pour être résolu (FIXED) ou qui risqueraient de casser d'autres choses ont de grandes chances de rester en l'état.
Release Candidate - une version candidate, ou RC, est une version ISO de la distribution qui sort pour trouver les bogues bloquants (show-stopper) sur les fonctionnalités et les paquets inclus. Pendant la phase de RC, aucun nouveau paquet ou fonctionnalité n'est ajouté, mais les bogues majeurs sont corrigés. Faites de votre mieux pour tester cette version de manière approfondie. Si elle marche bien, elle sera retenue en l'état et envoyée au distributeur pour réaliser les boîtes et les images ISO / répertoires en ligne mis à disposition des miroirs pour permettre les téléchargements. Les mainteneurs de paquets refusent toute montée de version, hormis pour un bogue bloquant. Seuls les bogues bloquants ou mise à jour de sécurité sont prises en compte à moins que la correction soit triviale et sans impact sur autre chose. Cela ne sert franchement à rien de réclamer une fonctionnalité à ce moment, vu que "aucune nouvelle fonctionnalité n'est ajoutée"
Contrib - les paquets qui ne font pas partie de la distribution principale (main), mais qui ont leur importance vu que quelqu'un a pris le temps de les mettre en paquet afin de contribuer.
Freeze - le "gel" correspond au fait qu'aucune fonctionnalité ne peut être ajoutée à des paquets de Mandriva GNU/Linux et aucune mise à jour de paquets, hormis pour des correction de bogues majeurs.
Deep Freeze - Seules les corrections de bogues bloquants et les alertes de sécurité peuvent être prises en compte.

TwikiCookerHowToFr