 |
Autres langues Deutsch ; English ; Français ; |
Contents
- 1 Qu’est-ce qu’une mise à jour
- 2 Où trouver des mises à jour candidate
- 3 Comment valider une mise à jour
- 4 Que faire si…
- 5 Plus d’informations
Qu’est-ce qu’une mise à jour
Une mise à jour est un nouveau paquet. Cela peut être une mise à jour de sécurité, une correction de bug pour un paquet existant, l’ajout d’une fonctionnalité ou un nouveau paquet, pas disponible avant.
Avant qu’elle ne soit “validée” par l’équipe QA elle est appelée « Mise à jour candidate » car c’est une candidate possible pour une mise à jour jusqu’à ce qu’elle passe le contrôle qualité QA et soit approuvée et ajoutée comme une mise à jour officielle de Mageia.
On appelle “validation” le processus de l’équipe QA pour tester une mise à jour candidate, envoyer des retours au packager, tester à nouveau quand le packager construit de nouveaux paquets pour corriger des erreurs et être sûr que la mise à jour candidate est prête avant d’être acceptée comme une mise à jour officielle de Mageia.
Où trouver des mises à jour candidate
Pour éviter les régressions, les mises à jour candidate sont placées dans un répertoire de test en attendant que l’Équipe QA les valide. Une requête correspondante de mise à jour sur le Bugzilla de Mageia est utilisée pour coordonner le processus de validation.
Une « demande de mise à jour » ressemble à un rapport de bug à l’exception du fait qu’il est demandé à l’équipe QA de tester la « mise à jour candidate » et qu’elle nous est assignée. Il n’est pas rare qu’un rapport de bug existant devienne une « demande de mise à jour », quand la « mise à jour candidate » a été créée pour corriger une erreur qui a été reportée.
Vous pouvez trouver des « demandes de mises à jour » de paquet en attente de « validation » ici.
Comment valider une mise à jour
Si vous avez empaqueté une mise à jour candidate, vous pouvez la tester sur une architecture pour accélérer les choses, mais vous '“devez”' fournir les détails de la procédure de test. La validation d’une mise à jour doit être laissée à l’équipe QA.
Identifier quelle architecture et version de Mageia vous utilisez
Dans le but de classer correctement votre travail de QA, il est nécessaire de connaître quelle architecture et version de Mageia que vous utilisez. Pour ce faire, tapez
| $ cat /etc/release |
dans un terminal ou ouvrez le fichier /etc/release dans un éditeur de texte et comparez la sortie avec le tableau suivant :
| Contenu de /etc/release | Architecture | Release (Version) | Whiteboard Keyword |
|---|---|---|---|
| Mageia release 5 (Official) for i586 | i586 | 5 | MGA3-32-OK |
| Mageia release 5 (Official) for x86_64 | x86_64 | 5 | MGA3-64-OK |
| Mageia release 6 (Official) for i586 | i586 | 6 | MGA4-32-OK |
| Mageia release 6 (Official) for x86_64 | x86_64 | 6 | MGA4-64-OK |
Prévenir les autres testeurs pour éviter de faire le travail en double
Dans le but de ne pas faire le même travail que l’équipe QA, dupliquer le travail, ajoutez un message à la demande de mise à jour sur Bugzilla quand vous commencez à travailler dessus. Quelque chose de simple pour faire savoir que vous travaillez dessus.
Un exemple de message à laisser :
Testing i586, MGA4.
| Remarque : « i586 » (Architecture) et « MGA4 » (Version) doit refléter ce qu’il y a sur votre système. |
Nous ne faisons pas toujours cela, car il y a généralement plus de bugs que de testeurs. Nous évitons de nous gêner, mais cela peut être utile si le test prend du temps ou si c’est un paquet populaire ou facile à tester.
Sur un gros paquet, important ou compliqué comme le kernel, KDE, Firefox, etc. cela peut être utile d’avoir plusieurs personnes qui testent simultanément. Cela accélère le processus de QA et le rend plus complet. C’est toujours plus utile de faire connaître ce que l’on teste. Ce n’est jamais mauvais d’être plus d’une personne à tester la même chose.
Tester les mises à jour candidates
Préparation
- Démarrer l’installation correcte et installez toutes les mises à jour officielles. Vérifiez le “Produit”, “Version” et “Plateforme” dans l’en-tête du rapport de bug pour les connaître, e.g. Mageia 4 x86_64. Notez aussi que certains bugs peuvent contenir des mises à jour pour plusieurs versions donc vérifiez aussi les informations de l’empaqueteur. Vous devriez avoir tous les médias de test désactivés à ce point.
L'Update Advisory Announcement Example est une description du pourquoi de cette mise à jour et de ce qui a été fait. C’est là que l’on sait ce qu’il faut tester. C’est ensuite envoyé sur le SVN par une personne qui y a accès et publié publiquement sur la page de Mageia, ainsi que sur la updates-announce liste de diffusion quand les mises à jour candidates sont publiées comme mise à jour.
Il y est aussi listé les RPM qui ont été mis à jour ainsi que leurs SRPMs. - Essayez de reproduire le bug avant d’installer le paquet mis à jour depuis le dépôt de test. C’est pour être rigoureux et prouver que vous pouvez vérifier que le bug est corrigé après la mise à jour. Il est aussi expliqué ce qu’il faut faire s’il ne l’est pas.
Si vous ne pouvez pas reproduire le bug, à cause d’un matériel non adapté par exemple, vous devriez quand même tester la mise à jour pour être sûr qu’il n’y a pas de nouveau bug. Vous pouvez aussi laisser un message demandant si quelqu’un peut faire le test complet, par exemple, quelqu’un avec le bon matériel. Le bon sens s’applique ici. Il est utile d’envoyer un mail sur la liste de diffusion ou celle des développeurs demandant si quelqu’un avec le bon matériel peu vous aider à tester.
Installer une mise à jour candidate
- Activez le dépôt testing correspondant dans vos sources. Voir la page Activer les dépôts Testing pour des instructions sur comment faire cela.
- Installer les mises à jour correspondantes, de préférence avec MageiaUpdate. N’installez pas tout ce qui vient du média testing, juste celui que vous êtes en train de tester. Soyez sûr de sélectionner tous les paquets correspondants, incluant les bibliothèques requises. (Astuce : vérifiez le numéro de version). Si vous installez la mise à jour depuis urpmi, n’oubliez pas d’installer également les bibliothèques.
- Désactivez le dépôt testing à nouveau
- Soyez sûr d’avoir maintenant la mise à jour candidate installée. Voyez Rechercher par nom parmi les paquetages installés pour plus d’instructions.
Tester
- Si c’est une mise à jour de sécurité vous verrez les numéros CVE dans le message d’information, ils doivent aussi être dans le sommaire du rapport de bug et l’empaqueteur rappelle souvent de mettre le “Component” à « Securité » aussi. Tenter de trouver une Proof of Concept (PoC) en ligne si elle n’est pas listée dans le sommaire du rapport de bug.
Il y a divers sites traitant de la sécurité. Un des plus populaires est securityfocus.com. Il permet de chercher en utilisant le numéro CVE et donne souvent des informations utiles ou des codes de Proof of Concept qui peuvent être utilisés pour vérifier que la vulnérabilité est corrigée. Si aucune n’est disponible testez juste pour vérifier des problèmes de régression et indiquez en commentaire que vous ne pouvez trouver aucun PoC pour éviter aux autres membres de chercher. Effectuez un test normal (vérifier les régressions). - Si c’est une correction de bug, vérifiez que le bug est corrigé en suivant le processus « en espérant » qu’il soit fourni dans la demande de mise à jour. Vous aurez sûrement à faire quelques recherches par vous-même, mais personne ne peut connaître tous les paquets. La page Trucs et Astuces AQ peut vous donner des idées pour tester un paquet. Vous pouvez aussi trouver des procédures de test en regardant la catégorie des procédures de test ou les ajouter si vous en trouvez qui ne sont pas notées. Si vous avez effectué des recherches mais ne trouvez pas comment effectuer le test vous pouvez laisser un message pour avoir plus d’informations.
- Faire des tests rapides pour vérifier que la mise à jour ne casse rien d’autre. Par exemple, tester les effets de bureaux ou si le DRI fonctionne comme prévu si la mise à jour concerne Xorg.
Rapport
- Si vos tests trouvent un problème alors reportez-le en laissant un commentaire sur le bug. L’empaqueteur peut vous demander plus d’information ou avoir besoin de plus de tests pour trouver le problème et préparer une solution pour le résoudre. Incluez la version et l’architecture sur laquelle vous avez fait vos tests.
Par exemple :
Testing Mageia 4 i586.
I found a problem…etc.
Note: « Mageia 4 » (Release) et i586 (Architecture) doivent correspondre à votre système. - Si tout est OK alors laissez un commentaire pour dire que vous avez complété les tests et ajouter un mot clé dans le tableau blanc (Whiteboard). Les mots clé du tableau blanc aident à garder une trâce quand un bug est prêt à être validé.
Par exemple :
Comment : « Testing complete Mageia 4 i586 for the srpm php-5.3.13-1.1.mga2.src.rpm
Whiteboard : « MGA4-32-OK
| Remarque : « Mageia 4 » (Release), “i586” (Architecture) et « MGA4-32-OK » (Whiteboard Keyword) doivent correspondre à votre système. |
- Vérifier si la mise à jour candidate est prête à être validée (voir ci-dessous)
Remarque :
|
Valider la mise à jour si elle est prête
Toutes les actions décrites ici sont relatives à Bugzilla.
- Vérifiez que la mise à jour candidate est prête pour validation Elle est prête pour validation seulement quand elle a été testée avec succès sur toutes les architectures et les versions couvertes. Comme certains bugs sont présents sur plusieurs versions de Mageia, chacun doit être corrigé sur les deux architectures i586 et x86_64 avant de pouvoir être validé.
Vous pouvez voir cela facilement sur sur madb où l’on voit un cercle vert à côté de chaque version lorsqu’elle est prête. - Ecrire un message de validation pour faire connaître aux autres que la mise à jour a été correctement testée sur les deux architectures et, si besoin, toutes les versions.
- Ajouter une liste de RPM sources testé / approuvé (SRPM's). Pour plus d’information pour trouver les SRPM pour un paquet, voyez la page Comment trouver un RPM source. Les SRPM sont souvent cités dans le bug avec la liste des paquets affectés. Aussi, l’en-tête du message de bug concernant les RPM peut en parler.
- Citez le message d’avertissement Soit copiez / collez le ou dites où vous pouvez le trouver.
- Ajoutez un message pour l’Équipe Sysadmin, demandant que le paquet soit avancé. Avancé le paquet veut dire qu’il passe d’un média à un autre. Pour le QA cela veut dire de demander aux sysadmins de pousser le SRPM du média de test où il est, vers le média de mise à jour associé. C’est actuellement tous les paquets contenus dans ce SRPM qui sont poussés. Ils seront ensuite disponibles pour tous les utilisateurs de Mageia comme une mise à jour valide.
Un exemple de commentaire à mettre :
------------------------------------------
Mise à jour validée.
Merci.
Message :
Cette mise à jour ajoute le support français pour le paquet xmoto. Il fixe aussi
les vulnérabilités de sécurité listées ci-dessous :
CVE-1234-5678 Ya Macallit a trouvé une vulnérabilité dans xmoto où les frites françaises
peuvent être servies froide en coupant la friteuse avant qu’elles ne soient cuites.
http://www.mitre.org/?cve-1234-5678
SRPM : xmoto.src.rpm
(Vous pouvez simplement dire quelque chose comme : Message dans les commentaires 3.)
Est-ce que le sysadmin peut pousser core/updates_testing vers core/updates.
Merci à vous !
------------------------------------------
Ensuite, en haut de la page : - Ajouter sysadmin-bugs@ml.mageia.org à la “CC” list pour que l’Équipe Sysadmin soit au courant que le paquet est prêt à être poussé. Sans cette étape ils ne sauront pas que le QA est complet et le paquet ne sera pas poussé vers les mises à jour donc ne l’oubliez pas !
- Ajoutez le mot clé « validate_update dans le champ texte « Mot Clé ».
- Cliquez sur “Sauvegarder”
| Remarque : Vous verrez normalement que quelqu’un mentionne que l’annonce a été envoyée. Ne vous inquiétez pas de cela. Le leader de l’équipe et les gens ayant les permissions requises envoient maintenant les annonces en fichier texte yaml vers svn où elles sont utilisées, quand la mise à jour est poussée, pour actualiser la liste de diffusion des annonces de mise à jour annonces sur le site et updates-announce. Elles sont envoyées avant que le sysadmin pousse la mise à jour et, une fois complète, notée avec une étoile (*) dans le premier champ sur madb et le tag “annonce” dans le champ tableau blanc de la demande sur Bugzilla. Seulement quelques membres du QA peuvent envoyer les annonces donc si vous voyez que celle-là en a besoin, laissez un message pour prévenir, pour être sûr qu’elle ne soit pas oubliée. |
Que faire si…
… la demande de mise à jour ne suit pas la politique des mises à jour
Si la demande de mise à jour manque trop d’informations comme l’annonce, les SRPM ou la procédure pour reproduire a bug laissez un message en demandant à l’empaqueteur de suivre la politique de mise à jour.
Par exemple :
S’il vous plaît suivez la politique de mise à jour et fournissez une annonce avec votre demande de mise à jour.
https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29
S’il vous plaît renvoyez la demande à l’équipe QA quand vous aurez vu ceci.
Merci.
Ensuite changez le status à ASSIGNED et réassignez le bug à la personne qui a demandé à l’équipe QA de le valider.
…la mise à jour candidate ne corrige pas le problème ou en cré un autre
Répondez simplement à la demande de mise à jour en donnant toutes les informations au sujet du bug ou de la régression ainsi que la version et l’architecture sur laquelle vous avez fait les tests. Préparez-vous à faire d’autres tests ou donner d’autres informations.
S’il n’y a pas de réponses après une semaine, réassignez le bug à l’empaqueteur et changez le status à ASSIGNED. Ajoutez aussi qa-bugs@ml.mageia.org en CC sur le bug afin que nous puissions répondre à l’empaqueteur quand il s’en occupera.
…vous avez besoin d’aide, d’être guidé, vous n’êtes pas sûr ou quoi que se soit
S’il vous plaît demandez ! La seule question idiote est celle que l’on ne pose pas, car on pense que c’est une question idiote. Vous pouvez demander sur IRC #mageia-qa sur Liberachat ou sur la liste de diffusion qa-discuss. S’il n’y a personne de disponible sur #mageia-qa vous pouvez aussi essayer #mageia-dev.
Plus d’informations
Vous pouvez vous réferrez au Portail de l’équipe AQ plus d’informations sur l’Equipe QA Mageia.
- La politique de mise à jour de Mageia.
- La page Trucs et Astuces AQ peut fournir des idées pour faire les tests.
- La liste de diffusion QA-Discuss : qa-discuss@ml.mageia.org
- La liste de diffusion QA-Bugs : qa-bugs@ml.mageia.org
- Vous pouvez aussi utiliser Mageia App Db pour voir les mises à jour en attente et faire des comparaisons.
- Sophie est un bot sur IRC qui donne des informations utiles sur les paquets de Mageia.
Essayez de taper : help sur #mageia-qa ou : more paquet
