Trier les bugs signalés

Tri des bugs

Ceci est une version modifiée d’un message de Boudewijn Rempt sur krita.org

Il existe de nombreuses manières d’aider Kdenlive, allant du codage à la rédaction de tutoriels, en passant par l’aide des utilisateurs sur les forums, à la diffusion de l’information et à la collecte de fonds. Mais examinons une tâche très importante : le tri des bugs.

Maintenant qu’il ya un nombre important d’utilisateurs Kdenlive et chaque année de nouvelles fonctionnalités, beaucoup de rapports de bugs sont envoyés. Et beaucoup de ces bugs sont semble-t-il spécifiques à la configuration de la machine de l’utilisateur. Certains bugs ne surviennent qu’avec certaines associations de matériel, de système d’exploitation et d’autres logiciels installés. Certains bugs surviennent pour tout le monde, mais ils sont rares, car peu de personnes utilisent une fonctionnalité de la même manière, et certains bugs se présentent aussi parce que nous sommes de modestes humains qui faisons des erreurs.

Chaque rapport doit être lu, de préférence par plusieurs personnes, qui peuvent essayer de déterminer :

s’ils peuvent déclencher le bogue – et dans ce cas, il faut le confirmer
s’ils ne comprennent pas le rapport ou s’ils déterminent qu’il est incomplet – et dans ce cas, il est nécessaire de demander plus d’informations
si le bug a déjà été signalé, et si c’est le cas, fil faut le fermer, en tant que duplicata du rapport précédent.

On utilise bugzilla de KDE pour suivre les bugs pour Kdenlive. Bugzilla est une application Web un brun ringarde mais qui a le mérite d’exister, et pour le moment, on devra faire avec. Voici ce que vous voyez lorsque vous recherchez des bugs Kdenlive “ouverts” :

Les informations importantes sont:

Composant (comp) : le bug concerne-t-il la documentation, les effets et transitions, l’installation, la traduction, l’interface utilisateur ou l’affichage et l’exportation vidéo ?
Statut (status) : UNCO signifie “Non confirmé”. Cela signifie que nous n’avons pas essayé de reproduire le bogue ou n’avons pas pu le reproduire.
Résumé (Summary) : une brève description du problème

Comme vous pouvez le constater, nous avons vraiment besoin d’aide ! JB est à la foist responsable du projet, développeur et gestionnaire. Même si l’équipe s’agrandit ces derniers temps, nous essayons de trier tous les bugs signalés mais n’arrivons pas à répondre à temps.

C’est là que vous entrez en scène ! Si vous êtes un utilisateur Kdenlive raisonnablement expérimenté et que vous souhaitez aider, voici comment vous préparer et configurer votre ordinateur :

Avoir un compte Bugzilla

Allez sur https://bugs.kdicie.org et cliquez sur “Create new Account”

Complétez le formulaire d’enregistrement et cliquez sur le lien de confirmation dans le courriel que vous allez recevoir.

Configurer les notifications par courriel

Connectez-vous à bugzilla et cliquez sur le bouton “Preferences” en haut, puis sur “Email Preferences”. Bugzilla peut envoyer beaucoup de courriels, mais heureusement, il inclut un certain nombre d’en-têtes spéciaux qui facilitent le filtrage du courrier de bugs dans des dossiers spéciaux de votre boîte de réception. Il y a deux étapes ; premièrement, donc, les préférences de messagerie (email preferences):

Et puis, un autre élément important : vous assurer que vous recevez un courrier électronique pour tous les bugs concernant Kdenlive. Ajoutez l’utilisateur “kdenlive-bugs-null@kde.org” à la liste des surveillance de l’utilisateur :

[Ici, on doit trouver un équivalent pour Kdenlive – Il n’y a pas de “kdenlive-bugs-null@kde.org” apparemment – voilà ce que cela donne avec Krita : https://krita.org/wp-content/uploads/2016/03/Spectacle.wZ7342.png]

A partir de ce moment là, vous recevrez un courriel chaque fois que quelque chose est modifié ou créé à propos d’un bug de Kdenlive. En utilisant les en-têtes spéciaux de Bugzilla, vous pouvez trier tout le courrier prêt à être traité :

X-Bugzilla-Reason: None X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: AssignedTo kdenlive-bugs-null@kde.org X-Bugzilla-Product: Kdenlive X-Bugzilla-Component: X-Bugzilla-Version: 16.04 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: [jb@kdenlive.org] X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: NOR X-Bugzilla-Assigned-To: kdenlive-bugs-null@kde.org X-Bugzilla-Target-Milestone: — X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter

Par exemple, vous pouvez diviser votre courrier concernant les bugs selon qu’il s’agit d’un nouveau bug, d’un bugs modifié, d’un nouveau souhait, d’un souhait modifié ou de la réponse à une requête «besoins-informations» (needs-info).

Trier un bug

Puis, lorsqu’un bug atterrit dans votre boîte de réception, vous pouvez l’ouvrir dans Bugzilla et le trier. Voic quelques étapes à suivre :

Vérifiez si c’est un “souhait” (Wish), si c’est le cas, laissez-le de coté. Les souhaits sont traités différement.
Vérifiez s’il s’agit d’un duplicata,. Si c’est le cas, fermez-le.
Vérifiez si le sujet est compréhensible et mentionne les informations les plus pertinentes ; sinon mettez-le à jour
Vérifiez si la version n’est pas trop ancienne. Actuellement, nous ne nous occupons que des bugs consernant les versions postérieures à 16.04.

Si un bug est signalé pour les versions antérieurs à 16.04, il doit être marqué comme NEEDSINFO et l’utilisateur doit essayer de reproduire le problème avec la version stable la plus récente. Remerciez l’utilisateur pour son rapport de bug. Gardez à l’esprit que signaler un bug peut être assez effrayant, en particulier pour les nouveaux utilisateurs, et que cela demande également un certain effort. Les rapporteurs de bugs sont également des contributeurs précieux !

Mais tout ceci n’était que les préliminaires : maintenant commence le vrai travail.

Essayer de reproduire le bogue. Au début, vous ne pourrez pas fermer les bugs ; Au début, tout ce que vous pouvez faire est d’ajouter des commentaires aux rapports. Si vous l’avez fait plusieurs fois, vous aurez appris le fonctionnement du système et vous serez familiarisé avec ce qui devrait être fait avec les nouveaux bugs. C’est le moment de demander à JB [jb@kdenlive.org] ou à Vincent [vpinon@kde.org] plus de pouvoirs !

– S’il est facile à reproduire, ajoutez des notes sur la manière dont vous avez obtenu le problème, sur votre distribution, votre version de Kdenlive, votre matériel et définissez le bug sur CONFIRMED.

– S’il n’y a pas assez d’informations pour reproduire le bug : Mettez le en NEEDSINFO et demandez plus d’informations à l’utilisateur.

– Si vous ne pouvez pas reproduire le bug même si le rapport est complet et que vous pouvez suivre toutes les étapes, notez que vous ne pouvez pas reproduire le bug, et demandez à l’utilisateur de le reproduire à nouveau. Mettez-le en NEEDSINFO et attendez. Si l’utilisateur répond qu’il ne peut pas le reproduire non plus, fermez le en tant que WORKSFORME.

– Si vous ne pouvez pas reproduire le bug, mais vous avez les éléments pour déduire que c’est déjà corrigé, ajoutez un commentaire sur le bug, mais ne modifiez pas encore son statut. Il est possible que l’utilisateur ne réalise tout simplement pas qu’il utilise Kdenlive de manière inappropriée, par exemple en mélangeant l’audio à 48 kHz et à 44,1 kHz. Orienté le vers le manuel et fermez avec NEEDSINFO. Si l’utilisateur répond que c’est le cas, le bug peut-être fermé.

– Si le bug est en lien avec un périphérique matériel, par exemple ShuttlePro. [Que devrait-on faire ici? quelque chose de différent ?]

Et c’est tout.

Maintenant, commencez à trier les bugs et gagnez notre gratitude éternelle ! L’aide au tri des bugs est une contribution réelle et durable à Kdenlive !