Rapports de bugs

Identification des bugs

Avant de faire un rapport de bug, s'il vous plaît, lisez et relisez la documentation pour vérifier si vous ne pouvez réellement pas faire ce que vous êtes en train d'essayer. Si ce n'est pas clair dans la documentation, soit vous pouvez faire quelque chose soit non; c'est un bug dans la documentation. Si votre programme fait quelque chose de différent de ce que la documentation dit, c'est un bug. Ceci inclut mais n'est pas limité à ces circonstances :

• Un programme se termine brutalement ou le système d'exploitation vous envoie un message qui pointe vers un problème dans le programme. (Un contre-exemple peut être un message de "disk full", dans ce cas vous règlerez le problème vous-même).

• Un programme produit une sortie erronée pour n'importe quelle donnée entrée.

• Un programme refuuse d'accepter des entrées valides (comme définies dans la documentation).

• Un programme accepte une entrée invalide sans renvoyer un message d'erreur. Mais garder à l'esprit que votre idée d'entrée invalide pourrait être notre idée d'une extension ou d'une compatibilité avec la pratique traditionnelle.

• PostgreSQL n'arrive pas à se compiler, et à s'installer selon les instructions pour les plates-formes concernées.

Une leuteur dans l'exécution ou une occupation des ressources n'est pas nécessairement un bug. Lisez la documentation ou demandez de l'aide sur une des mailing-lists. Une erreur de conformité avec le standard SQL n'est pas nécessairement un bug.

Avant de continuer, verifiez sur la liste TODO et dans la FAQ pour voir si votre bug est déja connu. Si vous ne pouvez décoder l'information sur la liste TODO, rapporter votre problème.

Que rapporter

La chose la plus importante en ce qui concerne les rapports de bugs est de rapporter les faits et rien que les faits. Ne spéculez pas sur ce que vous pensez être une erreur, ce "qu'il vous semble", ou quelle partie du programme est fautive. Des explications peuvent être une aide mais ne se substituent pas aux faits. Rapporter les faits dans leur nudité est assez simple (vous pouvez faire un copier-coller depuis un écran).

Les points suivants peuvent être contenus dans un rapport de bug :

• L'ordre des étapes depuis le démarrage du programme est nécessaire pour reproduire le problème. Nous n'avons pas le temps de faire du "reverse engineering" sur votre schéma de base. Le meilleur format pour un test sur un problème de langage de requête est un fichier qui peut être lancé à travers le clientpsql qui indique le problème. (soyez sûrs de ne rien avoir dans votre fichier de démarrage ~/.psqlrc).

  Si votre application utilise d'autres interfaces clientes comme PHP, essayez d'isoler les requêtes en question. Nous n'installerons pas un serveur web pour reproduire votre problème. D'un autre côté fournissez les fichiers d'entrée exacts, nous ne pouvons pas deviner si le problème apparaît sur des "gros fichiers" ou sur des bases de "taille moyenne", etc.

• Pour les sorties que vous obtenez. S'il vous plaît, ne dites pas "ça ne marche pas" ou "ça crashe". S'il y a un message d'erreur, indiquez le, même si vous ne le comprenez pas. Si le programme se termine avec une erreur du système d'exploitation, dites le aussi. Si rien ne se produit dites le. Même si le résultat de votre test est un crash du programme ou quelque chose d'évident il peut ne pas apparaître sur notre plate-forme. La chose la plus silmple est de copier l'écran du terminal si possible.

  En cas d'erreur fatale, le message d'erreur du client peut ne pas contenir toute l'information disponible. Regardez aussi le fichier log du serveur.

• La sortie que vous attendez est très importante. Si vous écrivez juste "cette commande me donne ça" ou "ce n'est pas ce que j'attendais", nous pouvons essayer nous-mêmes et penser que ça fonctionne comme vous le voulez. Nous n'avons pas le temps de décoder la sémantique exacte de vos commandes.

• Les options de ligne de commande et autres options de démarrage, incluent des variables d'environnement et des fichiers de configuration. Si vous utilisez une distribution qui lance le serveur de la base lors du boot, assayez de voir comment ça fonctionne.

• Tout est différent des instructions d'installation.

• Version de PostgreSQL. Vous pouvez lancer la commande SELECT version(); pour connaître la version du serveur auquel vous êtes connecté. La plupart des programmes exécutables supportent l'option --version; au moins postmaster --version et psql --version doivent fonctionner. Si vous utilisez une version pré-packagée, comme les RPMs, dites le, incluant les erreurs que les packages peuvent avoir. Idem si vous parlez d'un CVS, en incluant les dates et heures.

  Si votre version est plus ancienne que la 7.2 Nous vous dirons certainement que mettre à jour. Il y a des tonnes de corrections de bugs dans chaque nouvelle version, c'est pourquoi nous faisons de nouvelles versions.

• Informations sur la plate-forme. Ceci inclut le nom du noyau et la version, le bibliothèque C, le processeur, et la mémoire. Dans la plupart des cas il est suffisant de rapporter la marque et la version. Si vous avez des problèmes d'installation, l'information sur les compilateurs, make, etc. est aussi nécessaire.

Quand vous écrivez un rapport de bug, choisissez une terminologie qui ne soit pas confuse. Le logiciel complet s'appelle "Postgres" en bref. Si vous parlez précisément du serveur, mentionnez le, ne dites pas simplement "Postgres crashe". Un crash d'un seul processus serveur est tout à fait différent du crash d'un processus "postmaster" parent; ne dites pas "le postmaster crashe" quand vous indiquez un seul processus serveur, et vice et versa. De même, les programmes clients comme "psql" sont complètement séparés du serveur. Essayez d'être précis sur l'endroit où se trouve le problème, côté client ou côté serveur.

Où rapporter vos bugs

En général, envoyez les sur la mailing list concernée <pgsql-bugs@postgresql.org>. Il vous sera demandé d'utiliser un sujet descriptif dans votre mail.

Une autre méthode est de remplir le formulaire web disponible sur http://www.postgresql.org/. Envoyez un rapport de bug de cette façon génère un mail vers la mailing list <pgsql-bugs@postgresql.org>.

N'envoyez pas de rapport de bug sur les mailing lists d'utilisateurs, comme <pgsql-sql@postgresql.org> ou <pgsql-general@postgresql.org>. Ces mailing lists sont des réponses aux questions des utilisateurs et les abonnés ne désirent pas recevoir les rapports de bug. Plus important, il est très peu probable qu'ils puissent corriger eux-mêmes.

De même, s'il vous plaît n'envoyez pas de rapports sur les mailing lists des développeurs <pgsql-hackers@postgresql.org>. Cette liste est destinée aux discussions sur le développement de PostgreSQL et il serait bien si nous pouvions conserver les rapports de bugs séparés. Nous pouvons choisir d'en parler sur pgsql-hackers, si le problème le nécessite.

Si vous avez des problèmes avec la documentation, le meilleur endroit pour faire un rapport est la mailing list <pgsql-docs@postgresql.org>. Soyez précis sur la partie de la documentation qui vous pose problème.

Si votre bug est un problème de portabilité sur une plate-forme non supportée, envoyez un mail sur <pgsql-ports@postgresql.org>, ainsi nous (et vous) pourrons travailler au portage de PostgreSQL sur votre plate-forme.

À cause du spam, toutes les mailing lists ci-dessus sont modérées. Donc, vous devez vous inscrire à une liste pour pouvoir y poster. (Vous n'avez pas besoin d'être inscrit pour utiliser la forme web du rapport de bug cependant). Si vous voulez envoyez un mail mais pas recevoir tout le traffic de la liste, vous pouvez vous abonner en utilisant l'option nomail. Pour plus d'information envoyez un mail à <majordomo@postgresql.org> avec le simple mot help dans le corps du message.