forked from gleu/pgdocs_fr
/
problems.xml
387 lines (348 loc) · 17.6 KB
/
problems.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="bogue-reporting">
<title>Lignes de conduite pour les rapports de bogues</title>
<para>
Lorsque vous trouvez un bogue dans <productname>PostgreSQL</productname>,
nous voulons en entendre parler. Vos rapports de bogues jouent un rôle
important pour rendre <productname>PostgreSQL</productname> plus fiable car
même avec la plus grande attention, nous ne pouvons pas garantir que chaque
partie de <productname>PostgreSQL</productname> fonctionnera sur toutes les
plates-formes et dans toutes les circonstances.
</para>
<para>
Les suggestions suivantes ont pour but de vous former à la saisie d'un
rapport de bogue qui pourra ensuite être gérée de façon efficace. Il n'est
pas requis de les suivre mais ce serait à l'avantage de tous.
</para>
<para>
Nous ne pouvons pas promettre de corriger tous les bogues immédiatement. Si
le bogue est évident, critique ou affecte un grand nombre d'utilisateurs, il
y a de grandes chances pour que quelqu'un s'en charge. Il se peut
que nous vous demandions d'utiliser une version plus récente pour voir si le
bogue est toujours présent. Ou nous pourrions décider que le bogue ne peut
être corrigé avant qu'une réécriture massive, que nous avions planifiée, ne
soit faite. Ou peut-être est-ce trop difficile et que des choses plus
importantes nous attendent. Si vous avez besoin d'aide immédiatement,
envisagez l'obtention d'un contrat de support commercial.
</para>
<sect2>
<title>Identifier les bogues</title>
<para>
Avant de rapporter un bogue, merci de lire et re-lire la documentation pour
vérifier que vous pouvez réellement faire ce que vous essayez de faire. Si
ce n'est pas clair, rapportez-le aussi ; c'est un bogue dans la
documentation. S'il s'avère que le programme fait différemment de ce
qu'indique la documentation, c'est un bogue. Ceci peut inclure les
circonstances suivantes, sans s'y limiter :
<itemizedlist>
<listitem>
<para>
Un programme se terminant avec un signal fatal ou un message d'erreur du
système d'exploitation qui indiquerait un problème avec le programme.
(Un contre-exemple pourrait être le message <quote>disk full</quote>,
disque plein, car vous devez le régler vous-même.)
</para>
</listitem>
<listitem>
<para>
Un programme produit une mauvaise sortie pour une entrée donnée.
</para>
</listitem>
<listitem>
<para>
Un programme refuse d'accepter une entrée valide (c'est-à-dire telle que
définie dans la documentation).
</para>
</listitem>
<listitem>
<para>
Un programme accepte une entrée invalide sans information ou message
d'erreur. Mais gardez en tête que votre idée d'entrée invalide pourrait
être notre idée d'une extension ou d'une compatibilité avec les
pratiques traditionnelles.
</para>
</listitem>
<listitem>
<para>
<productname>PostgreSQL</productname> échoue à la compilation, à la
construction ou à l'installation suivant les instructions des
plateformes supportées.
</para>
</listitem>
</itemizedlist>
Ici, <quote>programme</quote> fait référence à un exécutable, pas au moteur
du serveur.
</para>
<para>
Une lenteur ou une absorption des ressources n'est pas nécessairement un
bogue. Lisez la documentation ou demandez sur une des listes de discussion
pour de l'aide concernant l'optimisation de vos applications. Ne pas se
conformer au standard <acronym>SQL</acronym> n'est pas nécessairement un
bogue sauf si une telle conformité est indiquée explicitement.
</para>
<para>
Avant de continuer, vérifiez sur la liste des choses à faire ainsi que dans
la FAQ pour voir si votre bogue n'est pas déjà connu. Si vous n'arrivez pas à
décoder les informations sur la liste des choses à faire, écrivez un rapport.
Le minimum que nous puissions faire est de rendre cette liste plus claire.
</para>
</sect2>
<sect2>
<title>Que rapporter ?</title>
<para>
Le plus important point à se rappeler avec les rapports de bogues est de
donner tous les faits et seulement les faits. Ne spéculez pas sur ce que vous
pensez qui ne va pas, sur ce qu'<quote>il semble faire</quote> ou sur quelle
partie le programme a une erreur. Si vous n'êtes pas familier avec
l'implémentation, vous vous tromperez probablement et vous ne nous aiderez
pas. Et même si vous avez raison, des explications complètes sont un bon
supplément mais elles ne doivent pas se substituer aux faits. Si nous pensons
corriger le bogue, nous devons toujours le reproduire nous-même. Rapporter
les faits stricts est relativement simple (vous pouvez probablement
copier/coller à partir de l'écran) mais, trop souvent, des détails importants
sont oubliés parce que quelqu'un a pensé qu'ils n'avaient pas d'importance ou
que le rapport serait compris.
</para>
<para>
Les éléments suivants devraient être fournis avec chaque rapport de
bogue :
<itemizedlist>
<listitem>
<para>
La séquence exacte des étapes nécessaires pour reproduire le problème
<emphasis>à partir du lancement du programme</emphasis>. Ceci devrait se
suffire ; il n'est pas suffisant d'envoyer une simple instruction
<command>SELECT</command> sans les commandes
<command>CREATE TABLE</command> et <command>INSERT</command>
qui ont précédé, si la sortie devrait dépendre des données contenues dans
les tables. Nous n'avons pas le temps de comprendre le schéma de votre
base de données. Si nous sommes supposés créer nos propres données, nous
allons probablement ne pas voir le problème.
</para>
<para>
Le meilleur format pour un test suite à un problème relatif à SQL est un
fichier qui peut être lancé via l'interface
<application>psql</application> et qui montrera le problème.
(Assurez-vous de ne rien avoir dans votre fichier de lancement
<filename>~/.psqlrc</filename>.) Un moyen facile pour créer ce fichier
est d'utiliser <application>pg_dump</application> pour récupérer les
déclarations des tables ainsi que les données nécessaires pour mettre en
place la scène. Il ne reste plus qu'à ajouter la requête posant problème.
Vous êtes encouragé à minimiser la taille de votre exemple mais ce n'est
pas une obligation. Si le bogue est reproductible, nous le trouverons de
toute façon.
</para>
<para>
Si votre application utilise une autre interface client, telle que
<application>PHP</application>, alors essayez d'isoler le problème aux requêtes
erronées. Nous n'allons certainement pas mettre en place un serveur web
pour reproduire votre problème. Dans tous les cas, rappelez-vous
d'apporter les fichiers d'entrée exacts ; n'essayez pas de deviner
que le problème se pose pour les <quote>gros fichiers</quote> ou pour les
<quote>bases de données de moyenne taille</quote>, etc. car cette
information est trop inexacte, subjective pour être utile.
</para>
</listitem>
<listitem>
<para>
La sortie que vous obtenez. Merci de ne pas dire que cela <quote>ne
fonctionne pas</quote> ou s'est <quote>arrêté brutalement</quote>. S'il
existe un message d'erreur, montrez-le même si vous ne le comprenez pas.
Si le programme se termine avec une erreur du système d'exploitation,
dites-le. Même si le résultat de votre test est un arrêt brutal du
programme ou un autre souci évident, il pourrait ne pas survenir sur
notre plateforme. Le plus simple est de copier directement la sortie du
terminal, si possible.
</para>
<note>
<para>
Si vous rapportez un message d'erreur, merci d'obtenir la forme la plus
verbeuse de ce message. Avec <application>psql</application>, exécutez <literal>\set
VERBOSITY verbose</literal> avant tout. Si vous récupérez le message des traces
du serveur, initialisez la variable d'exécution <xref
linkend="guc-log-error-verbosity"/> avec <literal>verbose</literal> pour que tous
les détails soient tracés.
</para>
</note>
<note>
<para>
Dans le cas d'erreurs fatales, le message d'erreur rapporté par le client
pourrait ne pas contenir toutes les informations disponibles. Jetez aussi un
œil aux traces du serveur de la base de données. Si vous ne
conservez pas les traces de votre serveur, c'est le bon moment pour
commencer à le faire.
</para>
</note>
</listitem>
<listitem>
<para>
Il est très important de préciser ce que vous attendez en sortie.
Si vous écrivez uniquement <quote>Cette commande m'a donné cette
réponse.</quote> ou <quote>Ce n'est pas ce que j'attendais.</quote>,
nous pourrions le lancer nous-même, analyser la sortie et penser que tout
est correct car cela correspond exactement à ce que nous attendions. Nous
ne devrions pas avoir à passer du temps pour décoder la sémantique exacte
de vos commandes. Tout spécialement, ne vous contentez pas de dire que
<quote>Ce n'est pas ce que SQL spécifie/Oracle fait.</quote> Rechercher le
comportement correct à partir de <acronym>SQL</acronym> n'est pas
amusant et nous ne connaissons pas le comportement de tous les autres
serveurs de base de données relationnels (Si votre problème est un arrêt
brutal du serveur, vous pouvez évidemment omettre cet élément.)
</para>
</listitem>
<listitem>
<para>
Toutes les options en ligne de commande ainsi que les autres options de
lancement incluant les variables d'environnement ou les fichiers de
configuration que vous avez modifié. Encore une fois, soyez exact. Si
vous utilisez une distribution pré-packagée qui lance le serveur au
démarrage, vous devriez essayer de retrouver ce que cette distribution
fait.
</para>
</listitem>
<listitem>
<para>
Tout ce que vous avez fait de différent à partir des instructions d'installation.
</para>
</listitem>
<listitem>
<para>
La version de <productname>PostgreSQL</productname>. Vous pouvez lancer la
commande <literal>SELECT version();</literal> pour trouver la version du
serveur sur lequel vous êtes connecté. La plupart des exécutables disposent
aussi d'une option <option>--version</option> ;
<literal>postgres --version</literal> et <literal>psql --version</literal>
devraient au moins fonctionner.
Si la fonction ou les options n'existent pas, alors votre version est bien
trop ancienne et vous devez mettre à jour. Si vous avez lancé une version
préparée sous forme de paquets, tel que les RPM, dites-le en incluant la
sous-version que le paquet pourrait avoir. Si vous êtes sur une version
Git, mentionnez-le en indiquant le hachage du commit.
</para>
<para>
Si votre version est antérieure à la &version;, nous allons certainement
vous demander de mettre à jour. Beaucoup de corrections de bogues et
d'améliorations sont apportées dans chaque nouvelle version, donc il est
bien possible qu'un bogue rencontré dans une ancienne version de
<productname>PostgreSQL</productname> soit déjà corrigé. Nous ne fournissons qu'un
support limité pour les sites utilisant d'anciennes versions de
<productname>PostgreSQL</productname> ; si vous avez besoin de plus de support
que ce que nous fournissons, considérez l'acquisition d'un contrat de
support commercial.
</para>
<para>
</para>
</listitem>
<listitem>
<para>
Informations sur la plate-forme. Ceci inclut le nom du noyau et sa version,
bibliothèque C, processeur, mémoires et ainsi de suite. Dans la plupart
des cas, il est suffisant de préciser le vendeur et la version mais ne
supposez pas que tout le monde sait ce que <quote>Debian</quote> contient
ou que tout le monde utilise des i386. Si vous avez des problèmes à
l'installation, des informations sur l'ensemble des outils de votre
machine (compilateurs, <command>make</command>, etc.) sont aussi
nécessaires.
</para>
</listitem>
</itemizedlist>
N'ayez pas peur si votre rapport de bogue devient assez long. C'est un fait.
Il est mieux de rapporter tous les faits la première fois plutôt que nous ayons à vous
tirer les vers du nez. D'un autre côté, si vos fichiers d'entrée sont trop
gros, il est préférable de demander si quelqu'un souhaite s'y plonger. Voici
un <ulink url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">article</ulink>
qui relève quelques autres conseils sur les rapports de bogues.
</para>
<para>
Ne passez pas tout votre temps à vous demander quelles modifications apporter
pour que le problème s'en aille. Ceci ne nous aidera probablement pas à le
résoudre. S'il arrive que le bogue ne peut pas être corrigé immédiatement,
vous aurez toujours l'opportunité de chercher ceci et de partager vos trouvailles.
De même, encore une fois, ne perdez pas votre temps à deviner pourquoi le
bogue existe. Nous le trouverons assez rapidement.
</para>
<para>
Lors de la rédaction d'un rapport de bogue, merci de choisir une terminologie
qui ne laisse pas place aux confusions. Le paquet logiciel en totalité est
appelé <quote>PostgreSQL</quote>, quelquefois <quote>Postgres</quote> en court.
Si vous parlez spécifiquement du serveur, mentionnez-le mais ne dites pas
seulement <quote>PostgreSQL a planté</quote>. Un arrêt brutal d'un seul processus
serveur est assez différent de l'arrêt brutal du
<quote>postgres</quote> père ; merci de ne pas dire que <quote>le serveur
a planté</quote> lorsque vous voulez dire qu'un seul processus s'est arrêté, ni
vice versa. De plus, les programmes clients tels que l'interface interactive
<quote><application>psql</application></quote> sont complètement séparés du
moteur. Essayez d'être précis sur la provenance du problème : client ou
serveur.
</para>
</sect2>
<sect2>
<title>Où rapporter des bogues ?</title>
<para>
En général, envoyez vos rapports de bogue à la liste de discussion des
rapports de bogue (<email>pgsql-bogues@postgresql.org</email>).
Nous vous demandons d'utiliser un sujet descriptif pour votre courrier
électronique, par exemple une partie du message d'erreur.
</para>
<para>
Une autre méthode consiste à remplir le formulaire web disponible sur le
<ulink url="http://www.postgresql.org/">site web</ulink> du projet.
Saisir un rapport de bogue de cette façon fait que celui-ci est envoyé à la
liste de discussion <email>pgsql-bogues@postgresql.org</email>.
</para>
<para>
Si votre rapport de bogue a des implications sur la sécurité et que vous
préfèreriez qu'il ne soit pas immédiatement visible dans les archives
publiques, ne l'envoyez pas sur <literal>pgsql-bugs</literal>. Les problèmes
de sécurité peuvent être rapportés de façon privé sur
<email>security@postgresql.org</email>.
</para>
<para>
N'envoyez pas de rapports de bogue aux listes de discussion des utilisateurs,
comme <email>pgsql-sql@postgresql.org</email> ou
<email>pgsql-general@postgresql.org</email>.
Ces listes de discussion servent à répondre aux questions des utilisateurs et
les abonnés ne souhaitent pas recevoir de rapports de bogues. Plus important,
ils ont peu de chance de les corriger.
</para>
<para>
De même, n'envoyez <emphasis>pas</emphasis> vos rapports de bogue à la liste
de discussion des développeurs <email>pgsql-hackers@postgresql.org</email>.
Cette liste sert aux discussions concernant le développement de
<productname>PostgreSQL</productname> et il serait bon de conserver les
rapports de bogue séparément. Nous pourrions choisir de discuter de votre
rapport de bogue sur <literal>pgsql-hackers</literal> si le problème
nécessite que plus de personnes s'en occupent.
</para>
<para>
Si vous avez un problème avec la documentation, le meilleur endroit pour le
rapporter est la liste de discussion pour la documentation
<email>pgsql-docs@postgresql.org</email>. Soyez précis sur la partie de la
documentation qui vous déplaît.
</para>
<para>
Si votre bogue concerne un problème de portabilité sur une plate-forme non
supportée, envoyez un courrier électronique à
<email>pgsql-hackers@postgresql.org</email>, pour que nous puissions travailler
sur le portage de <productname>PostgreSQL</productname> sur votre plate-forme.
</para>
<note>
<para>
Dû, malheureusement, au grand nombre de pourriels (spam), toutes les
adresses de courrier électronique ci-dessus appartiennent à des listes
de discussion fermées. C'est-à-dire que vous devez être abonné pour être
autorisé à y envoyer un courrier. Néanmoins, vous n'avez pas besoin de vous
abonner pour utiliser le formulaire web de rapports de bogue. Si vous
souhaitez envoyer des courriers mais ne pas recevoir le trafic de la liste,
vous pouvez vous abonner et configurer l'option <literal>nomail</literal>.
Pour plus d'information, envoyez un courrier à
<email>majordomo@postgresql.org</email>
avec le seul mot <literal>help</literal> dans le corps du message.
</para>
</note>
</sect2>
</sect1>