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
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
|
<!--
$FreeBSD$
%SOURCE% en_US.ISO8859-1/articles/problem-reports/article.sgml
%SRCID% 1.62
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//NL">
%articles.ent;
]>
<article lang="nl">
<articleinfo>
<title>Probleemrapporten voor &os; schrijven</title>
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
&tm-attrib.cvsup;
&tm-attrib.ibm;
&tm-attrib.intel;
&tm-attrib.sparc;
&tm-attrib.sun;
&tm-attrib.general;
</legalnotice>
<abstract>
<para>Dit artikel beschrijft hoe een probleemrapport het beste
geformuleerd en naar het &os; Project verzonden kan
worden.</para>
<para><emphasis>Vertaald door René Ladan</emphasis>.</para>
</abstract>
<authorgroup>
<author>
<firstname>Dag-Erling</firstname>
<surname>Smørgrav</surname>
<contrib>Bijgedragen door </contrib>
</author>
<author>
<firstname>Mark</firstname>
<surname>Linimon</surname>
</author>
</authorgroup>
</articleinfo>
<indexterm><primary>probleemrapporten</primary></indexterm>
<section id="pr-intro">
<title>Introductie</title>
<para>Eén van de meest frustrerende ervaringen die een
gebruiker van software kan hebben is om een probleemrapport in te
sturen om het vervolgens afgehandeld te zien met een korte en
onbehulpzame uitleg als <quote>geen bug</quote> of <quote>fout
PR</quote>. Evenzo is één van de meest
frustrerende ervaringen als ontwikkelaar van software om
overspoeld te worden met probleemrapporten die niet echt een
probleemrapport zijn maar ondersteuningsverzoeken, of die weinig
tot geen informatie bevatten over wat het probleem is en hoe het
te reproduceren.</para>
<para>Dit document poogt te beschrijven hoe goede probleemrapporten
te schrijven. Wat is een goed probleemrapport? Kort door de
bocht is een goed probleemrapport een rapport dat geanalyseerd kan
worden en waar snel mee kan worden omgegaan, voor de wederzijdse
voldoening van zowel de gebruiker als de ontwikkelaar.</para>
<para>Hoewel de nadruk van dit artikel ligt op probleemrapporten
voor &os;, zou het meeste ook in sterke mate op andere
softwareprojecten van toepassing moeten zijn.</para>
<para>Merk op dat dit artikel thematisch in plaats van chronologisch
is ingedeeld, dus u dient het hele document te lezen alvorens een
probleemrapport in te sturen, en het niet als een stapsgewijze
tutorial te behandelen.</para>
</section>
<section id="pr-when">
<title>Wanneer een probleemrapport te versturen</title>
<para>Er zijn vele soorten problemen, die niet allemaal geschikt
zijn voor een probleemrapport. Natuurlijk is niemand perfect dus
zal het soms voorkomen dat u overtuigd bent dat u een bug in een
programma heeft gevonden terwijl u in feite de syntaxis voor een
commando verkeerd begrepen heeft of een typefout in een
instellingenbestand gemaakt heeft (hoewel dat soms zelf al op
slechte documentatie of slechte foutafhandeling in de applicatie
kan wijzen). Er zijn nog steeds veel gevallen waarin het insturen
van een probleemrapport duidelijk <emphasis>niet</emphasis> de
juiste handeling is, en het alleen tot frustratie bij uzelf en de
ontwikkelaars leidt. Omgekeerd zijn er gevallen waarin het juist
kan zijn om een probleemrapport in te sturen over iets anders dan
een bug—bijvoorbeeld voor een verbetering of een
mogelijkheidsverzoek.</para>
<para>Dus hoe wordt bepaald of iets wel of niet een bug is? Een
eenvoudige vuistregel is dat uw probleem <emphasis>geen</emphasis>
bug is als het als een vraag kan worden uitgedrukt (meestal van de
vorm <quote>Hoe doe ik X?</quote> of <quote>Waar kan ik Y
vinden?</quote>). Het is niet altijd zo zwart-wit, maar de
vraagregel gaat in de meeste gevallen op. Overweeg, als u een
antwoord zoekt, om uw vraag aan de &a.questions; te
stellen.</para>
<para>Enkele gevallen waar het juist kan zijn om een probleemrapport
in te sturen over iets dat geen bug is zijn:</para>
<itemizedlist>
<listitem>
<para>Verzoeken om verbetering van mogelijkheden. Het is over
het algemeen een goed idee om deze op de mailinglijsten te
uiten alvorens een probleemrapport in te sturen.</para>
</listitem>
<listitem>
<para>Meldingen van updates aan extern onderhouden software
(over het algemeen ports, maar ook extern onderhouden
componenten van het basissysteem zoals BIND of verscheidene
gereedschappen van GNU).</para>
<para>Voor onbeheerde ports (<makevar>MAINTAINER</makevar> bevat
<literal>ports@FreeBSD.org</literal>) kan zo'n updatemelding
opgepakt worden door een geïnteresseerde committer, of u
kunt gevraagd worden om een patch aan te leveren om de port
bij te werken; door dit van te voren aan te bieden verhoogt u
in sterke mate de kans dat de port binnen een redelijk
tijdsbestek wordt bijgewerkt.</para>
<para>Als de port beheerd wordt, zijn PR's die nieuwe
stroomopwaartse uitgaven aankondigen niet erg nuttig aangezien
ze aanvullend werk voor de committers genereren, en
waarschijnlijk weet de beheerder al dat er een nieuwe versie
uit is, ze hebben er waarschijnlijk met de ontwikkelaars aan
gewerkt, ze zijn waarschijnlijk regressietesten aan het
uitvoeren, enzovoorts.</para>
<para>In beide gevallen zal het volgen van het proces zoals
beschreven in het <ulink
url="&url.books.porters-handbook.en;/port-upgrading.html">
Porters Handboek</ulink> tot de beste resultaten leiden. (U
bent misschien ook geïnteresseerd in <ulink
url="&url.articles.contributing-ports;/article.html">
Bijdragen aan de &os; Portscollectie</ulink>.)</para>
</listitem>
</itemizedlist>
<para>Een bug die niet reproduceerbaar is kan zelden gerepareerd
worden. Als een bug slechts eenmalig voorkwam en u deze niet kunt
reproduceren, en het bij niemand anders lijkt voor te komen, dan
bestaat de kans dat geen van de ontwikkelaars het kan reproduceren
of kan uitzoeken wat er mis is. Dit betekent niet dat het niet
gebeurde, maar wel dat de kans dat uw probleemrapport ooit tot een
reparatie leidt erg klein is. Om het allemaal erger te maken,
worden dit soort bugs vaak veroorzaakt door falende harde schijven
of oververhitte processoren — u dient altijd te proberen om
deze oorzaken, indien mogelijk, uit te sluiten voordat u een PR
instuurt.</para>
<para>Vervolgens, om te besluiten aan wie u uw probleemrapport dient
te sturen, moet u weten dat de software waaruit &os; bestaat uit
verschillende elementen is opgebouwd:</para>
<itemizedlist>
<listitem>
<para>Code in het basissysteem die geschreven is en onderhouden
wordt door &os;-vrijwilligers, zoals de kernel, de
C-bibliotheek, en de apparaatstuurprogramma's (gecategoriseerd
als <literal>kern</literal>); de binaire hulpmiddelen
(<literal>bin</literal>); de handleidingpagina's en
documentatie (<literal>docs</literal>); en de webpagina's
(<literal>www</literal>). Alle bugs in deze gebieden dienen
aan de &os;-ontwikkelaars gerapporteerd te worden.</para>
</listitem>
<listitem>
<para>Code in het basissysteem die geschreven is en onderhouden
wordt door anderen, en in &os; is geïmporteerd en
aangepast. Voorbeelden zijn <application>bind</application>,
&man.gcc.1;, en &man.sendmail.8;. De meeste bugs in deze
gebieden dienen aan de &os;-ontwikkelaars gerapporteerd te
worden; maar in sommige gevallen kan het zijn dat ze aan de
originele auteurs gerapporteerd moeten worden als de problemen
niet specifiek voor &os; zijn. Gewoonlijk vallen deze bugs in
ofwel de categorie <literal>bin</literal> ofwel de categorie
<literal>gnu</literal>.</para>
</listitem>
<listitem>
<para>Individuele applicaties die niet in het basissysteem
zitten maar in plaats daarvan deel zijn van de Portscollectie
van &os; (categorie <literal>ports</literal>). De meeste van
deze applicaties zijn niet geschreven door &os;-ontwikkelaars;
wat &os; biedt is slechts een raamwerk om de applicatie te
installeren. Daarom dient u alleen een probleem aan de
&os;-ontwikkelaars te rapporteren als u gelooft dat het
probleem specifiek voor &os; is; anders dient u het aan de
auteurs van de software te rapporteren.</para>
</listitem>
</itemizedlist>
<para>Daarna dient u vast te stellen of het probleem actueel is. Er
zijn maar weinig dingen die een ontwikkelaar meer irriteren dan
het ontvangen van een probleemrapport over een bug die reeds
gerepareerd is.</para>
<para>Als het probleem in het basissysteem zit, dient u eerst het
FAQ-gedeelte over <ulink
url="&url.books.faq.en;/introduction.html#LATEST-VERSION">
&os;-versies</ulink> te lezen als u niet reeds bekend bent met
het onderwerp. Het is niet mogelijk voor &os; om problemen in
iets anders dan bepaalde recente takken van het basissysteem op te
lossen, dus leidt het insturen van een bug-rapport over een oudere
versie waarschijnlijk alleen tot het advies van een ontwikkelaar
om naar een ondersteunde versie bij te werken om te kijken of het
probleem nog steeds voorkomt. Het Security Officer Team
onderhoudt de <ulink url="&url.base;/security/">lijst van
ondersteunde versies</ulink>.</para>
<para>Als het probleem in een port zit, moet u uw Portscollectie
eerst naar de laatste versie bijwerken en kijken of het probleem
nog steeds van toepassing is. Wegens de hoge snelheid waarmee
deze applicaties veranderen, is het onhaalbaar voor &os; om iets
anders dan de allernieuwste versies te ondersteunen, problemen met
oudere versies van applicaties kunnen simpelweg niet worden
opgelost.</para>
</section>
<section id="pr-prep">
<title>Voorbereidingen</title>
<para>Een goede regel is om altijd een vooronderzoek te doen voordat
u een probleemrapport ingestuurd. Misschien is uw probleem reeds
gerapporteerd; misschien wordt het besproken op de mailinglijsten,
of gebeurde dat recentelijk; misschien is het al gerepareerd in
een nieuwere versie dan die u draait. Om deze redenen dient u
alle voor de hand liggende plaatsen te controleren voordat u uw
probleemrapport instuurt. Voor &os; betekent dit:</para>
<itemizedlist>
<listitem>
<para>De &os;-lijst van
<ulink url="&url.books.faq.en;/index.html">Veelgestelde
Vragen</ulink> (FAQ). De FAQ probeert antwoord te geven op
een breed scala aan vragen, zoals die die betrekking hebben op
<ulink url="&url.books.faq.en;/hardware.html">compatibiliteit van
hardware</ulink>,
<ulink url="&url.books.faq.en;/applications.html">
gebruikersapplicaties</ulink>, en
<ulink url="&url.books.faq.en;/kernelconfig.html">
kernelconfiguratie</ulink>.</para>
</listitem>
<listitem>
<para>De
<ulink
url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">
mailinglijsten</ulink>—als u niet geabonneerd bent,
gebruik dan <ulink
url="http://www.FreeBSD.org/search/search.html#mailinglists">
de doorzoekbare archieven</ulink> op de &os;-website. Als
uw probleem niet op de lijsten bediscussieerd is, kunt u
proberen om er een bericht over te posten en enkele dagen
wachten om te zien of iemand iets kan zien wat u misschien
over het hoofd heeft gezien.</para>
</listitem>
<listitem>
<para>Optioneel, het gehele web—gebruik uw favoriete
zoekmachine om referenties naar uw probleem te vinden. U kunt
zelfs hits krijgen van gearchiveerde mailinglijsten of
nieuwsgroepen die u niet kende of waarvan u er niet aan had
gedacht om die te doorzoeken.</para>
</listitem>
<listitem>
<para>Vervolgens, de doorzoekbare
<ulink url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
&os; PR-database</ulink> (GNATS). Tenzij uw probleem recent
of obscuur is, bestaat er een redelijke kans dat het reeds
gerapporteerd is.</para>
</listitem>
<listitem>
<para>Het belangrijkste is dat u probeert te controleren of
bestaande documentatie in de bronnen uw probleem
bespreekt.</para>
<para>Voor de basis-&os;-code dient u zorgvuldig de inhoud van
het bestand <filename>/usr/src/UPDATING</filename> op uw
systeem of de laatste versie ervan op <ulink
url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING"></ulink>
te bestuderen. (Dit is essentiële informatie als u van
de ene naar een andere versie bijwerkt—in het bijzonder
als u naar de tak &os.current; bijwerkt.)</para>
<para>Als het probleem echter zit in iets wat als deel van de
&os; Portscollectie was geïnstalleerd, dan dient u
<filename>/usr/ports/UPDATING</filename> (voor individuele
ports) of <filename>/usr/ports/CHANGES</filename> (voor
veranderingen die de gehele Portscollectie beïnvloeden)
te raadplegen.
<ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING"></ulink>
en
<ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES"></ulink>
zijn ook beschikbaar via CVSweb.</para>
</listitem>
</itemizedlist>
</section>
<section id="pr-writing">
<title>Het probleemrapport schrijven</title>
<para>Nu u besloten heeft dat uw probleem een probleemrapport
verdiend, en het een probleem met &os; is, is het tijd om het
eigenlijke probleemrapport te schrijven. Voordat het mechanisme
van het programma dat gebruikt wordt om PR's aan te maken en in te
sturen wordt behandeld, zijn hier wat tips en trucs die ervoor
zorgen dat uw PR het meest effectief is.</para>
<section>
<title>Tips en trucs voor het schrijven van een goed
probleemrapport</title>
<itemizedlist>
<listitem>
<para><emphasis>Laat de regel <quote>Synopsis</quote> niet
leeg.</emphasis> De PR's gaan zowel naar een mailinglijst
die over de gehele wereld wordt verspreid (waar de
<quote>Synopsis</quote> wordt gebruikt voor de
<literal>Onderwerp:</literal>-regel), als in een database.
Iedereen die later de database op samenvatting doorzoekt, en
een PR met een lege onderwerpsregel aantreft, zal het
waarschijnlijk gewoon overslaan. Onthoud dat PR's in deze
database blijven staan totdat iemand ze sluit; een anoniem
PR zal slechts in de massa opgaan.</para>
</listitem>
<listitem>
<para><emphasis>Voorkom het gebruik van een zwakke
<quote>Synopsis</quote>-regel.</emphasis> U mag niet
aannemen dat iemand die uw PR leest enige achtergrondkennis
van uw inzending heeft, dus des meer u biedt, des te beter.
Op welk deel van het systeem heeft het probleem betrekking?
Ziet u het probleem alleen tijdens het installeren, of
tijdens het draaien? Ter illustratie, in plaats van
<literal>Synopsis: portupgrade is broken</literal>, zie
hoeveel informatiever dit lijkt: <literal>Synopsis: port
pors-mgmt/portupgrade coredumps on -current</literal>.
(In het geval van ports is het bijzonder behulpzaam om zowel
de categorie als de portnaam in de
<quote>Synopsis</quote>-regel te vermelden.)</para>
</listitem>
<listitem>
<para><emphasis>Als u een patch heeft, zeg dat dan.</emphasis>
Het is veel waarschijnlijker dat een PR met daarin een patch
bekeken wordt dan een PR zonder patch. Als u een patch
bijsluit, plaats dan de tekst <literal>[patch]</literal>
(inclusief de haken) aan het begin van de
<quote>Synopsis</quote>. (Alhoewel het niet verplicht is om
die exacte tekst te gebruiken, is dat per conventie degene
die gebruikt wordt.)</para>
</listitem>
<listitem>
<para><emphasis>Als u een onderhouder bent, zeg dat
dan.</emphasis> Als u een deel van de broncode onderhoudt
(bijvoorbeeld een port), kunt u overwegen om de tekst
<literal>[maintainer update]</literal> (inclusief de haken)
aan het begin van de onderwerpsregel te plaatsen, en dient u
zeker de <quote>Class</quote> van uw PR op
<literal>maintainer-update</literal> te zetten. Op deze
manier hoeft de committer die uw PR behandelt dit niet te
controleren.</para>
</listitem>
<listitem>
<para><emphasis>Ben specifiek.</emphasis> Des te meer
informatie u aanlevert over wat voor probleem u heeft, des
te groter is de kans dat u een antwoord krijgt.</para>
<itemizedlist>
<listitem>
<para>Vermeld de versie van &os; die u draait (hier is een
plaats voor, zie hieronder) en op welke architectuur dat
is. U dient aan te geven of u een uitgave draait
(bijvoorbeeld een CD-ROM of een download), of een
systeem dat met &man.cvsup.1; wordt onderhouden (en
zo ja, hoe recentelijk u dat heeft bijgewerkt). Als u
de tak &os.current; volgt, is dat het allereerste wat
iemand zal vragen, omdat reparaties (in het bijzonder
voor opvallende problemen) de neiging hebben om snel
gecommit te worden, en gebruikers van &os.current;
worden geacht om hun zaken bij te houden.</para>
</listitem>
<listitem>
<para>Vermeld welke globale opties u in uw
<filename>make.conf</filename> heeft gespecificeerd.
Noot: het specificeren van <literal>-O2</literal> en
hoger aan &man.gcc.1; staat in veel situaties als
bug-gevoelig bekend. Hoewel de &os;-ontwikkelaars
patches zullen accepteren, zijn ze over het algemeen
niet bereid om zulke gevallen te onderzoeken vanwege een
simpel gebrek aan tijd en vrijwilligers, en zullen ze in
plaats hiervan antwoorden met dat dit gewoon niet
ondersteund is.</para>
</listitem>
<listitem>
<para>Als het probleem eenvoudig gereproduceerd kan
worden, neem dan informatie op die een ontwikkelaar
helpt om het probleem zelf te reproduceren. Al een
probleem kan worden gedemonstreerd met specifieke
invoer, neem dan een voorbeeld van die invoer op indien
mogelijk, en neem zowel de eigenlijke als de verwachte
uitvoer op. Als deze gegevens groot zijn of niet
gepubliceerd kunnen worden, probeer dan om een minimaal
bestand te maken dat hetzelfde probleem vertoont en dat
in het PR kan worden opgenomen.</para>
</listitem>
<listitem>
<para>Als het een probleem met de kernel betreft, reken er
dan op om de volgende informatie aan te leveren. (U
hoeft deze niet standaard bij te sluiten, wat alleen de
database opvult, maar u dient uittreksel bij te sluiten
die u relevant acht):</para>
<itemizedlist>
<listitem>
<para>uw kernelconfiguratie (inclusief welke
hardware-apparaten u heeft
geïnstalleerd)</para>
</listitem>
<listitem>
<para>of u wel of niet debug-opties aan heeft staan
(zoals <literal>WITNESS</literal>), en zo ja, of het
probleem zich blijft voordoen als u de optie
omkeert</para>
</listitem>
<listitem>
<para>de volledige tekst van elke backtrace, panic of
andere console-uitvoer, of regels in
<filename>/var/log/messages</filename> als die waren
gegenereerd</para>
</listitem>
<listitem>
<para>De uitvoer van <command>pciconf -l</command> en
relevante gedeelten van uw uitvoer van
<command>dmesg</command> als uw probleem te maken
heeft met een bepaald stuk hardware.</para>
</listitem>
<listitem>
<para>het feit dat u
<filename>/usr/src/UPDATING</filename> heeft
gelezen en dat uw probleem daar niet staat vermeld
(iemand gaat er geheid naar vragen)</para>
</listitem>
<listitem>
<para>of u wel of niet op het draaien van een andere
kernel kunt terugvallen (dit is om problemen
gerelateerd aan hardware zoals falende schijven en
oververhitte CPU's uit te sluiten, welke zich als
kernelprobleem kunnen vermommen)</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Als het een probleem met de ports betreft, reken er
dan op om de volgende informatie aan te leveren. (U
hoeft deze niet standaard bij te sluiten, wat alleen de
database opvult, maar u dient uittreksels bij te sluiten
die u relevant acht):</para>
<itemizedlist>
<listitem>
<para>welke ports u heeft geïnstalleerd</para>
</listitem>
<listitem>
<para>alle omgevingsvariabelen die de standaardwaarden
in <filename>bsd.port.mk</filename> overschrijven,
zoals <makevar>PORTSDIR</makevar></para>
</listitem>
<listitem>
<para>het feit dat u
<filename>/usr/ports/UPDATING</filename> heeft
gelezen en dat uw probleem daar niet staat vermeld
(iemand gaat er geheid naar vragen)</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Voorkom vage verzoeken voor
mogelijkheden.</emphasis> PR's van de vorm <quote>iemand
moet echt iets dat zus-en-zo doet implementeren</quote>
leveren minder waarschijnlijk resultaat op dan zeer
specifieke verzoeken. Onthoud dat de broncode voor iedereen
beschikbaar is, dus als u een mogelijkheid wilt is de beste
manier om het erin te krijgen aan het werk te gaan! Neem
ook het feit in overweging dat veel van dit soort dingen
beter op <literal>freebsd-questions</literal> besproken
kunnen worden dan als een regel in de PR-database, zoals
hierboven besproken.</para>
</listitem>
<listitem>
<para><emphasis>Verzeker u ervan dat niemand anders reeds een
soortgelijk PR heeft ingestuurd.</emphasis> Alhoewel dit al
hierboven genoemd is, is het het herhalen hier waard. Het
duurt slechts een minuut of twee om de webgebaseerde
zoekmachine op <ulink
url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
</ulink> te gebruiken. (Natuurlijk vergeet iedereen dit zo
nu en dan.)</para>
</listitem>
<listitem>
<para><emphasis>Rapporteer slechts één zaak per
Probleemrapport.</emphasis> Voorkom het bijsluiten van
twee of meer problemen in hetzelfde rapport tenzij ze
gerelateerd zijn. Voorkom, wanneer patches worden
bijgevoegd, het toevoegen van meerdere mogelijkheden of het
repareren van meerdere bugs in hetzelfde PR tenzij ze sterk
gerelateerd zijn—het oplossen van zulke PR's duurt
vaak langer.</para>
</listitem>
<listitem>
<para><emphasis>Voorkom controversiële
verzoeken.</emphasis> Als uw PR een gebied behandelt dat in
het verleden controversieel was, dient u waarschijnlijk
bereid te zijn om niet alleen patches, maar ook een
verklaring waarom de patches <quote>Het Juiste Ding Om Te
Doen</quote> zijn aan te leveren. Zoals hierboven
vermeld, is het zorgvuldig doorzoeken van de mailinglijsten
door gebruik te maken van de archieven op <ulink
url="http://www.FreeBSD.org/search/search.html#mailinglists">
</ulink> altijd een goede voorbereiding.</para>
</listitem>
<listitem>
<para><emphasis>Ben beleefd.</emphasis> Bijna iedereen die aan
uw PR zal werken is een vrijwilliger. Niemand houdt ervan
om te horen dat ze iets moeten doen wat ze al aan het doen
zijn voor een andere motivatie dan geld. Dit is iets goeds
om altijd in de gaten te houden bij Open Source
projecten.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Voordat u begint</title>
<para>Als u het programma &man.send-pr.1; gebruikt, zorg er dan
voor dat uw omgevingsvariabele <envar>VISUAL</envar> (of
<envar>EDITOR</envar> als <envar>VISUAL</envar> niet is
ingesteld) op iets zinnigs is ingesteld.</para>
<para>U dient er ook zeker van te zijn dat het afleveren van mail
goed werkt. &man.send-pr.1; gebruikt mailberichten voor het
insturen en volgen van probleemrapporten. Als u geen
mailberichten kunt posten op de machine waarop u &man.send-pr.1;
draait, zal uw probleemrapport de GNATS-database niet bereiken.
Zie voor details over het opzetten van mail op &os; het
hoofdstuk <quote>Elektronische post</quote> van het &os;
Handboek op
<ulink url="http://www.FreeBSD.org/doc/nl_NL.ISO8859-1/books/handbook/mail.html"></ulink>.</para>
<para>Verzeker u ervan dat uw mailprogramma het bericht onderweg
naar GNATS niet vermangelt. In het bijzonder zal elke patch die
u instuurt onbruikbaar worden, als uw mailer automatisch regels
afbreekt, tabs in spaties verandert, of nieuwe-regel-tekens
escapet. Voor de tekstgedeelten vragen wij u echter om
handmatig regels rond de 70 tekens af te breken, zodat de
webversie van het PR leesbaar is.</para>
<para>Dezelfde soort overwegingen gelden als u het <ulink
url="&url.base;/send-pr.html">webgebaseerde
PR-instuurformulier</ulink> in plaats van &man.send-pr.1;
gebruikt. Merk op dat knip-en-plakbewerkingen hun eigen
bijwerkingen op tekstopmaak kunnen hebben. In bepaalde gevallen
kan het nodig zijn om &man.uuencode.1; te gebruiken om er zeker
van te zijn dat patches ongewijzigd aankomen.</para>
<para>Ten slotte, als uw inzending lang is, dient u uw werk
offline voor te bereiden zodat er niets verloren gaat indien er
zich een probleem met het inzenden ervan voordoet. Dit kan in
het bijzonder een probleem zijn met het <ulink
url="&url.base;/send-pr.html">webformulier</ulink>.</para>
</section>
<section>
<title>Patches of bestanden bijvoegen</title>
<para>Het volgende geldt voor het versturen van PR's via
email:</para>
<para>Het programma &man.send-pr.1; heeft voorzieningen voor het
bijvoegen van bestanden aan een probleemrapport. U kunt zoveel
bestanden bijvoegen als u wilt op voorwaarde dat elk bestand een
unieke basisnaam (i.e. de naam van het bestand zelf, zonder het
pad) heeft. Gebruik de opdrachtregeloptie <option>-a</option>
om de namen van de bij te voegen bestanden te
specificeren:</para>
<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/fouten</userinput></screen>
<para>Maakt u zich geen zorgen over binaire bestanden, deze worden
automatisch gecodeerd zodat ze de mail-agent niet
verontrusten.</para>
<para>Als u een patch bijvoegt, gebruik dan de optie
<option>-c</option> of <option>-u</option> van &man.diff.1; om
een context- of verenigde diff (verenigd is geprefereerd) aan te
maken, en zorg ervoor dat u de exacte revisienummers uit CVS
specificeert van de bestanden die u heeft gewijzigd zodat de
ontwikkelaars die uw rapport lezen ze gemakkelijk kunnen
toepassen. Voor problemen met de kernel of de
basisgereedschappen is een patch tegen &os.current; (de CVS-tak
HEAD) geprefereerd aangezien alle nieuwe code eerst daar
toegepast en getest dient te worden. Nadat het voldoende of
substantieel is getest, wordt de code samengevoegd of gemigreerd
naar de tak &os.stable;.</para>
<para>Als u een patch inline in plaats van als bijlage bijvoegt,
merk dan op dat het meest voorkomende probleem de neiging is van
sommige email-programma's om tabs als spaties weer te geven, wat
alles dat bedoeld was als deel van een Makefile volledig
ruineert.</para>
<para>Stuur geen patches als bijlagen door gebruik te maken van
<command>Content-Transfer-Encoding: quoted-printable</command>.
Dit zal karakter-escaping uitvoeren en de gehele patch
waardeloos maken.</para>
<para>Merk ook op dat hoewel het over het algemeen goed is om
kleine patches in een PR op te nemen—in het bijzonder als
ze het probleem dat in het PR beschreven is oplossen—grote
patches en in het bijzonder nieuwe code waarvoor
substantiële review nodig kan zijn voordat het gecommit
wordt op een web- of FTP-server geplaatst dient te worden, en de
URL in plaats van de patch bij het PR gevoegd dient te worden.
Patches in email hebben de neiging om gemangeld te worden, in
het bijzonder wanneer GNATS erbij betrokken is, en hoe groter de
patch, des te moeilijker het is voor geïnteresseerde
partijen om het te ontrafelen. Ook stelt het posten van een
patch op het web u in staat om het te wijzigen zonder dat het
nodig is om de gehele patch opnieuw in te zenden als een
vervolgbericht op het originele PR. Ten slotte vergroten grote
patches simpelweg de omvang van de database, aangezien gesloten
PR's niet worden verwijderd maar in plaats daarvan worden
bewaard en simpelweg als <literal>closed</literal> worden
gemarkeerd.</para>
<para>U dient ook te weten dat tenzij u het expliciet in uw PR of
in de patch zelf vermeld, dat van alle patches die u instuurt
wordt aangenomen dat ze onder dezelfde licentietermen vallen als
het originele bestand dat u heeft gewijzigd.</para>
</section>
<section>
<title>Het sjabloon invullen</title>
<para>De volgende sectie heeft alleen betrekking op de
email-methode:</para>
<para>Wanneer u &man.send-pr.1; draait, wordt er een sjabloon aan
u gepresenteerd. Het sjabloon bestaat uit een lijst met velden,
waarvan sommige al zijn ingevuld, en waarvan bij anderen staat
uitgelegd wat de bedoeling is of wat acceptabele waarden zijn.
Maakt u zich geen zorgen over het commentaar, deze worden
automatisch verwijderd wanneer u ze niet wijzigt of ze zelf
verwijdert.</para>
<para>Bovenaan het sjabloon, onder de regels met
<literal>SEND-PR:</literal>, staan de email-koppen. U hoeft
deze normaalgesproken niet te wijzigen, tenzij u het
probleemrapport vanaf een machine of account verstuurt die wel
mail kan versturen maar niet kan ontvangen; in dat geval wilt u
waarschijnlijk de velden <literal>From:</literal> en
<literal>Reply-To:</literal> op uw echte emailadres instellen.
U kunt uzelf (of iemand anders) een carbonkopie van het
probleemrapport versturen door één of meer
emailadressen aan de kop <literal>Cc:</literal> toe te
voegen.</para>
<para>In het email-sjabloon vindt u de volgende twee velden van
één regel:</para>
<itemizedlist>
<listitem>
<para><emphasis>Submitter-Id:</emphasis> Verander dit niet.
De standaardwaarde <literal>current-users</literal> is
juist, zelfs als u &os.stable; draait.</para>
</listitem>
<listitem>
<para><emphasis>Confidential:</emphasis> Dit is vooraf
ingevuld met <literal>no</literal>. Het heeft geen zin om
dit te veranderen aangezien er geen vertrouwelijk &os;
probleemrapport bestaat—de PR-database wordt
wereldwijd gedistribueerd door
<application>CVSup</application>.</para>
</listitem>
</itemizedlist>
<para>De volgende sectie beschrijft velden die zowel in de
email-interface als in de <ulink
url="&url.base;/send-pr.html">webinterface</ulink>
voorkomen:</para>
<itemizedlist>
<listitem>
<para><emphasis>Originator:</emphasis>
Specificeer hier alstublieft uw echte naam, eventueel
gevolgd door uw emailadres in punthaken. In de
email-interface wordt dit normaalgesproken vooraf ingevuld
met het <literal>gecos</literal>-veld van de huidige
aangemelde gebruiker.</para>
<note>
<para>Het emailadres dat u gebruikt wordt publieke
informatie en kan in de handen van spammers vallen. U
dient òfwel maatregelen te treffen om spam af te
handelen, òf een tijdelijk emailaccount te
gebruiken. Merk op dat als u een in het geheel ongeldig
emailaccount gebruikt, wij u geen vragen over uw PR kunnen
stellen.</para>
</note>
</listitem>
<listitem>
<para><emphasis>Organization:</emphasis> Alles waarvan u
vrolijk wordt. Dit veld wordt niet voor iets significants
gebruikt.</para>
</listitem>
<listitem>
<para><emphasis>Synopsis:</emphasis> Vul hier een korte en
accurate beschrijving van het probleem in. De samenvatting
wordt gebruikt als het onderwerp van de email van het
probleemrapport, en wordt gebruikt in lijsten en
samenvattingen van probleemrapporten; probleemrapporten met
een obscure samenvatting hebben de neiging om genegeerd te
worden.</para>
<para>Zoals hierboven vermeld, als uw probleemrapport een
patch bevat, begin dan alstublieft de samenvatting met
<literal>[patch]</literal> (inclusief de haken); als het een
ports-PR is en u de port onderhoudt, overweeg dan om
<literal>[maintainer update]</literal> (inclusief de haken)
toe te voegen en de <quote>Class</quote> van uw PR op
<literal>maintainer-update</literal> te zetten.</para>
</listitem>
<listitem>
<para><emphasis>Severity:</emphasis> Eén van
<literal>non-critical</literal>,
<literal>serious</literal> of
<literal>critical</literal>. Overdrijf niet, bestempel uw
probleem niet als <literal>critical</literal> tenzij het
dat echt is (bijvoorbeeld gevallen van gegevenscorruptie,
serieuze functionele regressie ten opzichte van een vorige
-CURRENT) of als <literal>serious</literal> tenzij het
iets is dat vele gebruikers aangaat (kernelpanics of
bevriezingen; problemen met bepaalde
apparaatstuurprogramma's of systeemgereedschappen).
&os;-ontwikkelaars zullen niet noodzakelijk sneller aan uw
probleem werken als u de belangrijkheid ervan opblaast
aangezien er vele anderen zijn die precies hetzelfde
gedaan hebben — in feite schenken sommige
ontwikkelaars weinig aandacht aan dit veld vanwege deze
redenen.</para>
<note>
<para>Grote beveiligingsproblemen dienen
<emphasis>niet</emphasis> naar GNATS gestuurd te worden,
omdat alle GNATS-informatie publieke kennis is. Stuur
zulke problemen alstublieft per privé-mail naar
het &a.security-officer;.</para>
</note>
</listitem>
<listitem>
<para><emphasis>Priority:</emphasis> Eén van
<literal>low</literal>, <literal>medium</literal> of
<literal>high</literal>. <literal>high</literal> dient te
worden gereserveerd voor problemen die bijna iedere
gebruiker van &os; aangaan en <literal>medium</literal> voor
iets dat vele gebruikers aangaat.</para>
<note>
<para>Dit veld is zo vaak misbruikt dat het bijna volledig
zinloos is geworden.</para>
</note>
</listitem>
<listitem>
<para><emphasis>Category:</emphasis> Kies een geschikte
categorie.</para>
<para>Het eerste wat u moet doen is beslissen in welk gebied
van het systeem uw probleem ligt. Onthoud dat &os; een
compleet besturingssysteem is, dat zowel een kernel, de
standaardbibliotheken, vele hulpstuurprogramma's, en een
groot aantal gereedschappen (het
<quote>basissysteem</quote>) installeert. Er zijn echter
duizenden aanvullende applicaties in de Portscollectie. U
dient eerst te beslissen of het probleem in het basissysteem
zit of dat het in iets dat via de Portscollectie
geïnstalleerd is zit.</para>
<para>Hier volgt een beschrijving van de grote
categoriën:</para>
<itemizedlist>
<listitem>
<para>Als er een probleem met de kernel, de bibliotheken
(zoals de standaard C-bibliotheek
<literal>libc</literal>), of een hulpstuurprogramma is,
gebruikt u in het algemeen de categorie
<literal>kern</literal>. (Er zijn enkele uitzonderingen
die hieronder vermeld staan). In het algemeen zijn dat
dingen die in sectie 2, 3, of 4 van de
handleidingpagina's staan beschreven.</para>
</listitem>
<listitem>
<para>Als er een probleem met een binair programma zoals
&man.sh.1; of &man.mount.8; is, dient u eerst te bepalen
of deze programma's deel zijn van het basissysteem of
dat ze via de Portscollectie zijn toegevoegd. Als u het
niet zeker weet, kunt u <command>whereis
<replaceable>programmanaam</replaceable></command>
uitvoeren. De conventie van &os; voor de Portscollectie
is om alles onder <filename
class="directory">/usr/local</filename> te
installeren, alhoewel dit door een systeembeheerder
veranderd kan worden. Voor dezen gebruikt u de
categorie <literal>ports</literal> (zelfs als de
categorie van de port <literal>www</literal> is; zie
hieronder). Als de locatie
<filename class="directory">/bin</filename>,
<filename class="directory">/usr/bin</filename>,
<filename class="directory">/sbin</filename>, of
<filename class="directory">/usr/sbin</filename> is,
dan is het een onderdeel van het basissysteem, en dient
u de categorie <literal>bin</literal> te gebruiken.
(Enkele programma's, zoals &man.gcc.1;, gebruiken
eigenlijk de categorie <literal>gnu</literal>, maar
daarover hoeft u zich nu geen zorgen te maken.) Dit
zijn allemaal programma's die in sectie 1 of 8 van de
handleidingpagina's worden beschreven.</para>
</listitem>
<listitem>
<para>Als u denkt dat de fout in de opstartscripts
<literal>(rc)</literal> zit, of in een ander type
onuitvoerbaar configuratiebestand, dan is de juiste
categorie <literal>conf</literal> (configuratie). Deze
dingen worden in sectie 5 van de handleidingpagina's
beschreven.</para>
</listitem>
<listitem>
<para>Als u een probleem in de documentatie (artikelen,
boeken, handleidingpagina's) heeft gevonden, dan is de
juiste keuze <literal>docs</literal>.</para>
</listitem>
<listitem>
<para>Als u een probleem heeft met de
<ulink url="&url.base;">&os; webpagina's</ulink>, dan is
de juiste <literal>www</literal>.</para>
<note>
<para>Als u problemen heeft met iets dat van een port
genaamd <literal>www/<replaceable>portnaam</replaceable></literal>
afkomt, dan hoort dit desalniettemin in de categorie
<literal>ports</literal> thuis.</para>
</note>
</listitem>
</itemizedlist>
<para>Er zijn nog enkele gespecialiseerde
categoriën:</para>
<itemizedlist>
<listitem>
<para>Als het probleem in <literal>kern</literal> gestopt
zou worden maar met het USB-subsysteem te maken heeft,
dan is de juiste keuze <literal>usb</literal>.</para>
</listitem>
<listitem>
<para>Als het probleem in <literal>kern</literal> gestopt
zou worden maar het met de threading-bibliotheken te
maken heeft, dan is de juiste keuze
<literal>threads</literal>.</para>
</listitem>
<listitem>
<para>Als het probleem in het basissysteem zit, maar het
met onze naleving van standaarden zoals &posix; te maken
heeft, dan is de juiste keuze
<literal>standards</literal>.</para>
</listitem>
<listitem>
<para>Als het probleem te maken heeft met interne fouten
van de &java.virtual.machine; (&jvm;), dan dient u de
categorie <literal>java</literal> te kiezen, zelfs als
was &java; vanuit de Portscollectie geïnstalleerd.
Meer algemene problemen met &java;-ports horen nog
steeds onder <literal>ports</literal> thuis.</para>
</listitem>
</itemizedlist>
<para>Dit laat al het andere achter.</para>
<itemizedlist>
<listitem>
<para>Als u ervan overtuigd bent dat het probleem zich
alleen voordoet onder de processorarchitectuur die u
gebruikt, kies dan één van de
architectuurspecifieke categoriën: gewoonlijk
<literal>i386</literal> voor Intel-compatibele machines
in 32-bit-modus; <literal>amd64</literal> voor
AMD-machines die in 64-bit-modus draaien (dit omvat ook
Intel-compatibele machines die in EMT64-modus draaien);
en minder gewoonlijk <literal>arm</literal>,
<literal>ia64</literal>, <literal>powerpc</literal>, en
<literal>sparc64</literal>.</para>
<note>
<para>Deze categoriën worden vaak misbruikt voor
<quote>Ik weet het niet</quote>-problemen. Gebruik
alstublieft <literal>misc</literal>, in plaats van te
raden.</para>
</note>
<example>
<title>Correct gebruik van een arch-specifieke
categorie</title>
<para>U heeft een gewone PC-gebaseerde machine, en denkt
dat u een probleem bent tegengekomen dat specifiek is
voor een bepaalde chipset of een bepaald moederbord:
<literal>i386</literal> is de juiste categorie.</para>
</example>
<example>
<title>Onjuist gebruik van een arch-specifieke
categorie</title>
<para>U heeft een probleem met een insteekkaart op een
veelvoorkomende bus, of een probleem met een bepaald
type harde schijfstation: in dit geval is het
waarschijnlijk op meer dan één
architectuur van toepassing, en is
<literal>kern</literal> de juiste categorie.</para>
</example>
</listitem>
<listitem>
<para>Als u echt niet weet waar het probleem zich bevindt
(of als de uitleg niet bij een van de bovenstaanden
lijkt te passen), gebruik dan de categorie
<literal>misc</literal>. Voordat u dit doet, kunt u
eerst hulp vragen aan de &a.questions;. U krijgt dan
misschien het advies dat een bestaande categorie echt
een betere keuze is.</para>
</listitem>
</itemizedlist>
<para>Hier is een actuele lijst van categoriën (van
<ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/send-pr/categories"></ulink>):</para>
<itemizedlist>
<listitem>
<para><literal>advocacy:</literal> problemen gerelateerd
aan het publieke imago van &os;. Overbodig.</para>
</listitem>
<listitem>
<para><literal>alpha:</literal> problemen specifiek aan
het platform Alpha.</para>
</listitem>
<listitem>
<para><literal>amd64:</literal> problemen specifiek aan
het platform AMD64.</para>
</listitem>
<listitem>
<para><literal>arm:</literal> problemen specifiek aan het
platform ARM.</para>
</listitem>
<listitem>
<para><literal>bin:</literal> problemen met
gebruikersprogramma's in het basissysteem.</para>
</listitem>
<listitem>
<para><literal>conf:</literal> problemen met
configuratiebestanden, standaardwaarden,
enzovoorts.</para>
</listitem>
<listitem>
<para><literal>docs:</literal> problemen met
handleidingpagina's of online documentatie.</para>
</listitem>
<listitem>
<para><literal>gnu:</literal> problemen met
geïmporteerde GNU-software zoals &man.gcc.1; of
&man.grep.1;.</para>
</listitem>
<listitem>
<para><literal>i386:</literal> problemen specifiek aan het
&i386;-platform.</para>
</listitem>
<listitem>
<para><literal>ia64:</literal> problemen specifiek aan het
ia64-platform.</para>
</listitem>
<listitem>
<para><literal>java:</literal> problemen gerelateerd aan
de &java; Virtual Machine.</para>
</listitem>
<listitem>
<para><literal>kern:</literal> problemen met de kernel,
(platforminspecifieke) apparaatstuurprogramma's, of
de basisbibliotheken.</para>
</listitem>
<listitem>
<para><literal>misc:</literal> alles wat niet in een van
de andere categoriën past. (Merk op dat er bijna
niets is wat echt in deze categorie past, behalve
problemen met de uitgave- en bouwinfrastructuur.
Tijdelijke bouwfouten op <literal>HEAD</literal> horen
hier niet thuis. Merk ook op dat dingen in deze
categorie gemakkelijk kwijtraken).</para>
</listitem>
<listitem>
<para><literal>ports:</literal> problemen gerelateerd aan
de Portscollectie.</para>
</listitem>
<listitem>
<para><literal>powerpc:</literal> problemen specifiek voor
het &powerpc;-platform.</para>
</listitem>
<listitem>
<para><literal>sparc64:</literal> problemen specifiek voor
het &sparc64;-platform.</para>
</listitem>
<listitem>
<para><literal>standards:</literal> Zaken met betrekking
tot conformatie aan standaarden.</para>
</listitem>
<listitem>
<para><literal>threads:</literal> problemen gerelateerd
aan de implementatie van threads op &os; (in het
bijzonder op &os.current;).</para>
</listitem>
<listitem>
<para><literal>usb:</literal> problemen gerelateerd aan de
implementatie van USB op &os;.</para>
</listitem>
<listitem>
<para><literal>www:</literal> Veranderingen of
verbeteringen aan de website van &os;.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Class:</emphasis> Kies één van
de volgenden:</para>
<itemizedlist>
<listitem>
<para><literal>sw-bug:</literal> softwarebugs.</para>
</listitem>
<listitem>
<para><literal>doc-bug:</literal> fouten in
documentatie.</para>
</listitem>
<listitem>
<para><literal>change-request:</literal> verzoeken voor
aanvullende mogelijkheden of veranderingen in bestaande
mogelijkheden.</para>
</listitem>
<listitem>
<para><literal>update:</literal> updates aan ports of
andere bijgedragen software.</para>
</listitem>
<listitem>
<para><literal>maintainer-update:</literal> updates aan
ports die u onderhoudt.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Release:</emphasis> De versie van &os; die u
draait. Dit wordt automatisch ingevuld als u
&man.send-pr.1; gebruikt en hoeft alleen veranderd te worden
als u een probleemrapport verstuurt vanaf een ander systeem
dan van hetgene waarop het probleem zich voordoet.</para>
</listitem>
</itemizedlist>
<para>Ten slotte zijn er een aantal meerregelige velden:</para>
<itemizedlist>
<listitem>
<para><emphasis>Environment:</emphasis> Dit dient zou
nauwkeurig mogelijk de omgeving te beschrijven waarin het
probleem is waargenomen. Dit omvat de versie van het
besturingssysteem, de versie van het specifieke programma of
bestand dat het probleem bevat, en alle andere relevante
zaken zoals systeemconfiguratie, andere geïnstalleerde
software dat het probleem beïnvloedt, enzovoorts—
eigenlijk alles wat een ontwikkelaar moet weten om de
omgeving te reconstrueren waarin het probleem
optreedt.</para>
</listitem>
<listitem>
<para><emphasis>Description:</emphasis> Een complete en
nauwkeurige beschrijving van het probleem dat u ondervindt.
Probeer speculaties over de oorzaken van het probleem te
vermijden tenzij u zeker weet dat u op het juiste spoor zit,
aangezien een ontwikkelaar hierdoor onjuiste aannames over
het probleem kan maken.</para>
</listitem>
<listitem>
<para><emphasis>How-To-Repeat:</emphasis> Een samenvatting van
de acties die nodig waren om het probleem te
reproduceren.</para>
</listitem>
<listitem>
<para><emphasis>Fix:</emphasis> Bij voorkeur een patch, of op
zijn minst een tijdelijke oplossing (wat niet alleen andere
mensen helpt om om het probleem heen te werken, maar
mogelijk ook een ontwikkelaar de oorzaak van het probleem
helpt te begrijpen), maar als u hier ook geen echte
ideëen over heeft is het beter om dit veld open te
laten dan om te speculeren.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Het probleemrapport versturen</title>
<para>Als u &man.send-pr.1; gebruikt:</para>
<para>Als u klaar bent met het invullen van het sjabloon, het
heeft opgeslagen, en uw tekstverwerker verlaten heeft, zal
&man.send-pr.1; u de prompt <prompt>s)end, e)dit or
a)bort?</prompt> tonen. U kunt dan <userinput>s</userinput>
aanslaan om het probleemrapport in te sturen,
<userinput>e</userinput> aanslaan om de tekstverwerker te
herstarten en verdere wijzigingen te maken, of
<userinput>a</userinput> aanslaan om te stoppen. Als u het
laatste kiest, blijft uw probleemrapport bewaard op schijf
(&man.send-pr.1; vertelt u de bestandsnaam voordat het eindigt),
zodat u het rustig kunt bewerken, of het misschien over kunt
plaatsen naar een systeem met een betere netverbinding, voordat
u het met de optie <option>-f</option> van &man.send-pr.1;
verstuurt:</para>
<screen>&prompt.user; <userinput>send-pr -f ~/mijn-probleemrapport</userinput></screen>
<para>Dit leest het gespecificeerde bestand, controleert de
geldigheid van de inhoud, verwijdert commentaar en verstuurt
het.</para>
<para>Als u het <ulink
url="&url.base;/send-pr.html">webformulier</ulink>
gebruikt:</para>
<para>Voordat u op <literal>submit</literal> drukt, moet u een
veld invullen waarin tekst staat dat als afbeelding op de pagina
wordt weergegeven. Deze ongelukkige maatregel moest worden
genomen vanwege het misbruik door geautomatiseerde systemen en
enkele kwaadwillige gebruikers. Het is noodzakelijk kwaad dat
niemand leuk vindt; vraag ons alstublieft niet om het te
verwijderen.</para>
<para>Merk op dat u <literal>ten zeerste wordt
aangeraden</literal> om uw werk ergens op te slaan voordat u
op <literal>submit</literal> drukt. Een veelvoorkomend probleem
voor gebruikers is dat hun webbrowser een verouderde afbeelding
uit de cache laat zien. Als u dit overkomt, wordt uw inzending
geweigerd en kan u uw werk verliezen.</para>
<para>Als u om een bepaalde reden geen afbeeldingen kunt bekijken,
en u ook &man.send-pr.1; niet kunt gebruiken, accepteer dan
alstublieft onze verontschuldigingen voor het ongemak en email
uw probleemrapport naar het bugbuster-team op
<email>freebsd-bugbusters@FreeBSD.org</email>.</para>
</section>
</section>
<section id="pr-followup">
<title>Vervolg</title>
<para>Als uw probleemrapport eenmaal is ingestuurd, ontvangt u een
bevestiging per email waarin het volgnummer dat aan uw
probleemrapport was toegewezen en een URL dat u kunt gebruiken om
de status te controleren zijn opgenomen. Met een beetje geluk zal
iemand interesse in uw probleem tonen en proberen het op te
lossen, of, wat het geval kan zijn, uitleggen waarom het geen
probleem is. U wordt automatisch op de hoogte gehouden van alle
toestandsveranderingen, en u ontvangt kopiën van al het
commentaar en patches die iemand aan het controletraject van uw
probleemrapport kan koppelen.</para>
<para>Als iemand aanvullende informatie van u vraagt, of als u zich
iets herinnert of iets ontdekt dat u niet in het initiële
rapport noemde, gebruik dan alstublieft één van de
twee methoden om uw vervolg in te sturen:</para>
<itemizedlist>
<listitem>
<para>De gemakkelijkste manier is om de vervolgkoppeling op de
webpagina van het individuele PR te gebruiken, welke u kunt
bereiken vanuit de <ulink
url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
PR-zoekpagina</ulink>. Het klikken op deze koppeling brengt
een email-venster naar voren met daarin de juiste regels voor
Aan: en Onderwerp: ingevuld (als uw browser is ingesteld om
dit te doen).</para>
</listitem>
<listitem>
<para>Als alternatief kunt u het naar &a.bugfollowup; mailen,
waarbij het volgnummer in het onderwerp is opgenomen zodat het
foutenvolgsysteem weet aan welk probleemrapport het het moet
koppelen.</para>
<note>
<para>Als u het volgnummer <emphasis>niet</emphasis> opgeeft,
raakt GNATS in de war en maakt het een geheel nieuw PR aan
welke het vervolgens aan de GNATS-beheerder toekent, en
vervolgens raakt uw PR kwijt totdat iemand de rommel
opruimt, wat dagen of weken later kan zijn.</para>
<para>Verkeerde manier:</para>
<programlisting>Onderwerp: that PR I sent</programlisting>
<para>Juiste manier:</para>
<programlisting>Onderwerp: Re: ports/12345: compilation problem with foo/bar</programlisting>
</note>
</listitem>
</itemizedlist>
<para>Als het probleemrapport open blijft nadat het probleem is
opgelost, stuur dan een vervolg (op de bovenstaande manier) waarin
u vertelt dat het probleemrapport gesloten kan worden, en indien
mogelijk, uitlegt hoe of wanneer het probleem was opgelost.</para>
</section>
<section id="pr-problems">
<title>Als u problemen heeft</title>
<para>De meeste PR's gaan door het systeem en worden snel
geaccepteerd; soms loopt GNATS echter achter en kan het zijn dat u
uw email-bevestiging pas na 10 minuten of zelfs later ontvangt.
Wees alstublieft geduldig.</para>
<para>Tevens geldt, omdat GNATS alle invoer via email ontvangt, dat
het absoluut noodzakelijk is dat &os; alle inzendingen door
spam-filters haalt. Als u binnen een uur of twee geen antwoord
krijgt, kan uw PR misschien zijn opgeslokt; als dit zo is, neem
dan alstublieft contact op met de GNATS-beheerders op
<email>bugmeister@FreeBSD.org</email> en vraag om hulp.</para>
<note>
<para>Een veelvoorkomende anti-spam-maatregel is het vergelijken
met vele vormen van misbruik die in HTML-gebaseerde email
voorkomen (alhoewel niet noodzakelijk het slechts opnemen van
HTML in een PR). We raden het gebruik van HTML-gebaseerde email
voor het versturen van PR's sterk af: niet alleen is het
waarschijnlijker dat het niet door de filters komt, het heeft
ook de neiging om de database te verstoppen. Oude platte email
wordt sterk geprefereerd.</para>
</note>
<para>In zeldzame gevallen zult een bug in GNATS tegenkomen waarbij
een PR geaccepteerd is en een volgnummer toegewezen heeft gekregen
maar waarbij het niet op de lijst van PR's van een van de
opvraag-webpagina's staat. Het kan zijn gebeurd dat de index van
database niet meer met de database zelf is gesynchroniseerd. De
manier waarop u dit kunt testen is door de webpagina <ulink
url="http://www.FreeBSD.org/cgi/query-pr.cgi">bekijk een enkel
PR</ulink> op te roepen en te kijken of het PR wordt vermeld.
Als dat zo is, stel dan alstublieft de GNATS-beheerders op
<email>bugmeister@FreeBSD.org</email> op de hoogte. Merk op dat
er een <literal>cron</literal>-taak is die de database periodiek
herbouwt, dus u hoeft geen actie te ondernemen tenzij u haast
heeft.</para>
</section>
<section id="pr-further">
<title>Verdere literatuur</title>
<para>Er is een lijst met bronnen die relevant is voor het juist
schrijven en verwerken van probleemrapporten. Het is in geen
geval compleet.</para>
<itemizedlist>
<listitem>
<para><ulink
url="http://www.chiark.greenend.org.uk/~sgtatham/bugs-nl.html">
Effectief softwarestoringen melden</ulink>—een uitstekend
essay door Simon G. Tatham over het samenstellen van nuttige
(niet-&os;-specifieke) probleemrapporten.</para>
</listitem>
<listitem>
<para><ulink
url="&url.articles.pr-guidelines.en;/article.html">Problem
Report Handling Guidelines</ulink>—waardevolle inzichten
in hoe probleemrapporten worden afgehandeld door de
&os;-ontwikkelaars.</para>
</listitem>
</itemizedlist>
</section>
</article>
|