1 files changed, 0 insertions, 41 deletions
diff --git a/website/content/fr/gnome/docs/bugging.adoc b/website/content/fr/gnome/docs/bugging.adoc
deleted file mode 100644
index e4c68426df..0000000000
--- a/website/content/fr/gnome/docs/bugging.adoc
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: "Projet GNOME pour FreeBSD : rapporter un bug"
-sidenav: gnome
---- 
-
-= Projet GNOME pour FreeBSD : rapporter un bug
-
-== 1. Quoi rapporter ?
-
-La première règle est : rapportez autant d'informations que vous pouvez. Même s'il y a des informations inutiles les développeurs pourront facilement les éliminer. Au contraire, la situation est bien pire lorsqu'il n'y a pas assez d'informations pour découvrir ou reproduire le problème - dans ce cas, les développeurs devront perdre du temps à deviner et/ou demander des précisions à l'auteur du rapport de bug.
-
-Il y a plein d'exemples de rapports de bugs totalement inutiles, du genre _"Hé, le port de gnomebidule est cassé. J'utilise FreeBSD-X.Y. Corrigez svp."_ Inutile de dire que de tels rapports sont juste un gaspillage de votre temps, du temps du développeur concerné et de bande passante. Au strict minimum, le rapport doit inclure les informations suivantes :
-
-* La version exacte du système d'exploitation (habituellement le résultat de `uname -a`).
-* La liste de tous les paquetages installés sur votre système.
-* Votre environnement (le résultat de `/usr/bin/env`).
-* Si vous faites une compilation à partir des ports, la date approximative où vous avez mis à jour les ports.
-* Des informations spécifiques à chaque type d'erreur : le log complet de la compilation dans le cas où la compilation d'un port est cassé, le contenu de la pile dans le cas d'un core dump, une description détaillée du problème lorsque cela concerne une application, etc. Essayez de vous mettre à la place du développeur et, pour chaque cas particulier, évaluez quelles informations peuvent être nécessaires pour qu'il puisse trouver la source du problème. Ne pensez pas que les développeurs connaissent déjà tout du problème et qu'ils sont juste trop paresseux pour le corriger.
-
-Par ailleurs, essayez de répondre aux questions suivantes :
-
-* *Quel est exactement le problème ?* : Expliquez le problème aussi clairement et précisément que possible. Essayez de limiter la description du problème à une ou deux phrases clés.
-* *Où survient le problème ?* : Dites si le problème intervient lors de la compilation, de l'installation, ou de l'exécution. Décrivez également la machine sur laquelle survient le problème (peut-être en avez-vous plusieurs) et avec quelle locale (i.e. quelle valeur de la valeur d'environnement *LANG*).
-* *Quand le problème est-il survenu pour la première fois ?* : Essayez de déterminer quand le problème a commencé à apparaître. Si ça n'a jamais marché ou que vous avez toujours eu un problème, dites le également. Dites aussi quand le problème a été observé pour la dernière fois, et, le cas échéant, quand les choses ont bien marché pour la dernière fois.
-* *Quelle est l'importance du problème ?* : Expliquez si les choses empirent, si elles s'améliorent, ou si elles restent les mêmes. Nous avons conscience que beaucoup de problèmes ne sont que des problèmes, mais ce genre d'information peut s'avérer utile dans certains cas.
-
-Tenez vous prêt à répondre à des questions supplémentaires. Bien souvent, les développeurs ne peuvent résoudre un problème ou même en faire le diagnostique tout de suite. Donc, montrez vous compréhensif lorsqu'on vous demandera de fournir d'autres informations.
-
-Si vous avez une solution ou un moyen de contourner le problème, mettez le également dans votre rapport, même si vous n'êtes pas certain que cette solution est correcte. Si elle ne l'est pas, elle peut tout de même donner au développeur des idées et lui faire gagner du temps.
-
-== 2. Où envoyer le rapport ?
-
-Avant de rapporter un bug, ou même d'envoyer un message sur la liste, http://www.freebsd.org/search/search.html[faites une recherche] dans les archives de la liste de diffusion GNOME pour FreeBSD pour voir s'il n'a pas déjà été rapporté. La plupart des problèmes rapportés sur les listes de diffusion sont déjà connus et, en faisant une recherche, vous pouvez trouver la solution à votre problème beaucoup plus rapidement.
-
-Une fois que vous êtes certain qu'il s'agit d'un problème nouveau, il y a plusieurs manières de rapporter un bug concernant GNOME sous FreeBSD : vous pouvez envoyer un rapport sur la mailto:freebsd-gnome@FreeBSD.org[liste de diffusion freebsd-gnome], remplir un rapport de problème avec http://www.freebsd.org/support/#gnats[le système de rapport de bug FreeBSD], envoyer votre rapport aux développeurs GNOME concernés via leur http://bugzilla.gnome.org/[système de gestion de bug] ou utiliser une combinaison de ces différentes méthodes.
-
-Il est impossible de définir des règles qui vous indiqueront clairement dans tous les cas où envoyer votre rapport - utilisez votre bon sens. Voici cependant quelques principes généraux :
-
-* Si le problème est spécifique à FreeBSD et temporaire (e.g. un checksum incorrect, un patch qui échoue, une erreur de syntaxe dans le Makefile du port, etc.) alors envoyez le rapport à la mailto:freebsd-gnome@FreeBSD.org[liste de diffusion freebsd-gnome].
-* Si le problème est clairement non spécifique à FreeBSD et que vous n'avez pas de solution disponible alors envoyez le rapport directement aux développeurs du logiciel (pour la plupart des composants du noyau de GNOME cela signifie que vous devrez utiliser leur système de gestion de bug "Bugzilla").
-* Si le problème n'est pas spécifique à FreeBSD mais assez sérieux et que vous avez une solution disponible alors envoyez le rapport à la fois à FreeBSD et au système de gestion de bug des auteurs, de façon à ce que le port concerné soit corrigé et que les autres utilisateurs FreeBSD puissent béneficier de votre solution sans avoir à attendre la sortie d'une nouvelle version du logiciel.