path: root/nl_NL.ISO8859-1/articles/problem-reports/article.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
	"../../../share/xml/freebsd45.dtd">

<!--
     $FreeBSD$
     %SOURCE%	en_US.ISO8859-1/articles/problem-reports/article.sgml
     %SRCID%	39544
-->

<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>

    <pubdate>$FreeBSD$</pubdate>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <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&oslash;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&mdash;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 &mdash; 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 vragen 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>&mdash;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&mdash;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&mdash;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&mdash;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&mdash;in het bijzonder als
	ze het probleem dat in het PR beschreven is oplossen&mdash;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>Alleen in het email-sjabloon vindt u de volgende 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&mdash;de PR-database wordt
	    wereldwijd gedistribueerd door
	    <application>CVSup</application>.</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
	    bevroren computers; 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 &mdash; in feite schenken sommige
	    ontwikkelaars weinig aandacht aan dit veld vanwege deze
	    redenen.</para>

	  <note>
	    <para>Beveiligingsproblemen dienen
	      <emphasis>niet</emphasis> naar GNATS gestuurd te worden,
	      omdat alle GNATS-informatie publieke kennis is.  Stuur
	      zulke problemen alstublieft volgens onze <ulink
		url="http://security.freebsd.org/#how">richtlijnen voor
		beveilingsrapportages.</ulink>.</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
	      betekenisloos is geworden.</para>
	  </note>
	</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>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&mdash;
	    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 het probleem te omzeilen, 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 vervolg
	  gekoppeld moet worden.</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>&mdash;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>&mdash;waardevolle inzichten
	  in hoe probleemrapporten worden afgehandeld door de
	  &os;-ontwikkelaars.</para>
      </listitem>
    </itemizedlist>
  </section>
</article>