Stations de travail en ligne OnWorks Linux et Windows

Logo

Hébergement gratuit en ligne pour les postes de travail

<Précédent | Table des matières | Suivant>

Conseils divers


Évitez de signaler des bugs en double. Dans le monde du logiciel libre, tous les outils de suivi des bugs sont publics. Les problèmes ouverts peuvent être consultés et ils disposent même d'une fonction de recherche. Ainsi, avant de signaler un bug, vérifiez si votre problème a déjà été signalé.

Si vous trouvez un rapport de bug existant, abonnez-vous et ajoutez éventuellement des informations complémentaires. Évitez les commentaires du type « Moi aussi » ou « +1 » ; ils sont inutiles. Vous pouvez toutefois indiquer que vous êtes disponible pour des tests supplémentaires si l'auteur initial ne l'a pas proposé.

Si vous n'avez trouvé aucun rapport concernant votre problème, n'hésitez pas à le signaler. Si vous avez trouvé des tickets associés, n'hésitez pas à les mentionner.

Assurez-vous d'utiliser la dernière version. Il est très frustrant pour les développeurs de recevoir des rapports de bugs pour des problèmes qu'ils ont déjà résolus ou qu'ils ne peuvent pas reproduire avec la version qu'ils utilisent (les développeurs utilisent presque toujours la dernière version de leur produit). Même lorsque les anciennes versions sont maintenues par les développeurs, le support se limite souvent aux correctifs de sécurité et aux problèmes majeurs. Êtes-vous sûr que votre bug en fait partie ?

C'est pourquoi, avant de déposer un rapport de bogue, vous devez vous assurer que vous utilisez la dernière version du système et de l'application problématiques et que vous pouvez reproduire le problème dans cette situation.

Si Kali Linux ne propose pas la dernière version de l'application (ni en kali-rolling ni en kali-bleeding-edge, voir la section 8.1.3.3, « Le référentiel Kali-Bleeding-Edge” [page 174]), vous avez des solutions alternatives : vous pouvez essayer une installation manuelle de la dernière version dans une machine virtuelle jetable, ou vous pouvez consulter le ChangeLog en amont (ou l'historique des commits Git) pour voir qu'il n'y a pas eu de changement qui pourrait résoudre le problème que vous voyez (et ensuite signaler le bug même si vous n'avez pas essayé la dernière version).

Ne mélangez pas plusieurs problèmes dans un même rapport de bug. Créez un rapport de bug par problème. Ainsi, les discussions ultérieures ne seront pas trop confuses et chaque bug pourra être corrigé selon son propre calendrier. Si vous ne le faites pas, soit le bug devra être réutilisé plusieurs fois et ne pourra être fermé qu'une fois tous les problèmes corrigés, soit les développeurs devront créer les rapports complémentaires que vous auriez dû créer initialement.


Meilleur système d'exploitation Cloud Computing chez OnWorks :