PERFORCE change 155023 for review
Rene Ladan
rene at FreeBSD.org
Fri Dec 19 09:39:09 PST 2008
http://perforce.freebsd.org/chv.cgi?CH=155023
Change 155023 by rene at rene_self on 2008/12/19 17:38:39
Translated up to 18% of problem-reports article (rev 1.60).
Affected files ...
.. //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#3 edit
Differences ...
==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#3 (text+ko) ====
@@ -1,17 +1,18 @@
+<!--
+ $FreeBSD: $
+ %SOURCE% en_US.ISO8859-1/articles/problem-reports/article.sgml
+ %SRCID% 1.60
+-->
+
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//EN">
%articles.ent;
]>
-<!--
- $FreeBDS: $
- %SOURCE% en_US.ISO8859-1/articles/problem-reports/article.sgml
- %SRCID% 1.60
--->
-<article>
+<article lang="nl">
<articleinfo>
- <title>Writing &os; Problem Reports</title>
+ <title>Probleemrapporten voor &os; schrijven</title>
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
@@ -24,15 +25,18 @@
</legalnotice>
<abstract>
- <para>This article describes how to best formulate and submit a
- problem report to the &os; Project.</para>
+ <para>Dit artikel beschrijft hoe een probleemrapport het beste
+ geformuleerd en naar het &os; Project verzonden kan
+ worden.</para>
+
+ <para><emphasis>Vertaald door door René Ladan</emphasis>.</para>
</abstract>
<authorgroup>
<author>
<firstname>Dag-Erling</firstname>
<surname>Smørgrav</surname>
- <contrib>Contributed by </contrib>
+ <contrib>Bijgedragen door </contrib>
</author>
<author>
@@ -42,179 +46,186 @@
</authorgroup>
</articleinfo>
- <indexterm><primary>problem reports</primary></indexterm>
+ <indexterm><primary>probleemrapporten</primary></indexterm>
<section id="pr-intro">
- <title>Introduction</title>
+ <title>Introductie</title>
- <para>One of the most frustrating experiences one can have as a
- software user is to submit a problem report only to have it
- summarily closed with a terse and unhelpful explanation like
- <quote>not a bug</quote> or <quote>bogus PR</quote>. Similarly,
- one of the most frustrating experiences as a software developer
- is to be flooded with problem reports that are not really
- problem reports but requests for support, or that contain little
- or no information about what the problem is and how to reproduce
- it.</para>
+ <para>Eén van de meest frusterende ervaringen die een
+ gebruiker van software kan hebben is om een probleemrapport in te
+ versturen 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
+ frusterende 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>This document attempts to describe how to write good problem
- reports. What, you ask, is a good problem report? Well, to go
- straight to the bottom line, a good problem report is one that
- can be analyzed and dealt with swiftly, to the mutual
- satisfaction of both user and developer.</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 wordne omgegaan, voor het wederzijdse
+ plezier van zowel de gebruiker als de ontwikkelaar.</para>
- <para>Although the primary focus of this article is on &os;
- problem reports, most of it should apply quite well to other
- software projects.</para>
+ <para>Hoewel de nadruk van dit artikel ligt op probleemrapporten
+ voor &os;, zou het meeste ook op andere softwareprojecten van
+ toepassing moeten zijn.</para>
- <para>Note that this article is organized thematically, not
- chronologically, so you should read through the entire document
- before submitting a problem report, rather than treat it as a
- step-by-step tutorial.</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 op te sturen, in plaats van het als een
+ stapsgewijze tutorial te behandelen.</para>
</section>
<section id="pr-when">
- <title>When to submit a problem report</title>
+ <title>Wanneer een probleemrapport te versturen</title>
- <para>There are many types of problems, and not all of them should
- engender a problem report. Of course, nobody is perfect, and
- there will be times when you are convinced you have found a bug
- in a program when in fact you have misunderstood the syntax for
- a command or made a typographical error in a configuration file
- (though that in
- itself may sometimes be indicative of poor documentation or poor
- error handling in the application). There are still many cases
- where submitting a problem report is clearly
- <emphasis>not</emphasis> the right
- course of action, and will only serve to frustrate you and the
- developers. Conversely, there are cases where it might be
- appropriate to submit a problem report about something else than
- a bug—an enhancement or a feature request, for
- instance.</para>
+ <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 of een typfout 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 frustatie 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>So how do you determine what is a bug and what is not? As a
- simple rule of thumb your problem is <emphasis>not</emphasis> a
- bug if it can be expressed as a question (usually of the form
- <quote>How do I do X?</quote> or <quote>Where can I find
- Y?</quote>). It is not always quite so black and white, but the
- question rule covers a large majority of cases. If you are looking
- for an answer, consider posing your question to the
- &a.questions;.</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 in 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>Some cases where it may be appropriate to submit a problem
- report about something that is not a bug are:</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>Requests for feature enhancements. It is generally a
- good idea to air these on the mailing lists before
- submitting a problem report.</para>
+ <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>Notification of updates to externally maintained
- software (mainly ports, but also externally maintained base
- system components such as BIND or various GNU
- utilities).</para>
+ <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 at 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 PRs 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>For unmaintained ports (<makevar>MAINTAINER</makevar> contains
- <literal>ports at FreeBSD.org</literal>), such update notifications
- might get picked up by an interested
- committer, or you might be asked to provide a patch to update
- the port; providing it upfront will greatly improve your chances
- that the port will get updated in a timely manner.</para>
-
- <para>If the port is maintained, PRs announcing new upstream releases
- are usually not very useful since they generate supplementary work
- for the committers, and the maintainer likely knows already there is
- a new version, they have probably worked with the developers on it,
- they are probably testing to see there is no regression, etc.</para>
-
- <para>In either case, following the process described in <ulink
- url="&url.books.porters-handbook;/port-upgrading.html">Porter's
- Handbook</ulink> will yield the best results. (You might
- also wish to read <ulink
- url="&url.articles.contributing-ports;/article.html">
- Contributing to the FreeBSD Ports Collection</ulink>.)
- </para>
+ <para>In beide gevallen zal het volgen van het proces zoals
+ beschreven in het <ulink
+ url="&url.books.porters-handbook;/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>A bug that can not be reproduced can rarely be
- fixed. If the bug only occurred once and you can not reproduce
- it, and it does not seem to happen to anybody else, chances are
- none of the developers will be able to reproduce it or figure
- out what is wrong. That does not mean it did not happen, but it
- does mean that the chances of your problem report ever leading
- to a bug fix are very slim. To make matters worse, often
- these kinds of bugs are actually caused by failing hard drives
- or overheating processors — you should always try to rule
- out these causes, whenever possible, before submitting a PR.</para>
+ <para>Een bug die niet reproduceerbaar is kan zelden gemaakt worden.
+ Als een bug slechts eenmalig voorkwam en u deze niet kunt
+ reproduceren, en het bijna 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 kansen dat uw probleemrapport ooit tot
+ een reparatie leidt erg klein zijn. 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 problemen, indien mogelijk, uit te sluiten
+ voordat u een PR instuurt.</para>
- <para>Next, to decide to whom you should file your problem
- report, you need to understand that the software that makes
- up &os; is composed of several different elements:</para>
+ <para>Vervolgens, voordat u besluit 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 the base system that is written and maintained
- by &os; contributors, such as the kernel, the C library,
- and the device drivers (categorized as <literal>kern</literal>);
- the binary utilities (<literal>bin</literal>); the manual
- pages and documentation (<literal>docs</literal>); and
- the web pages (<literal>www</literal>). All bugs in
- these areas should be reported to the &os; developers.</para>
+ <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 the base system that is written and maintained
- by others, and imported into &os; and adapted. Examples
- include <application>bind</application>, &man.gcc.1;, and
- &man.sendmail.8;. Most bugs in these areas should be reported
- to the &os; developers; but in some cases they may need to be
- reported to the original authors instead if the problems are
- not &os;-specific. Usually these bugs will fall under either
- the <literal>bin</literal> or <literal>gnu</literal>
- categories.</para>
+ <para>Code in het basissysteem die geschreven is en onderhouden
+ wordt door anderen, en geïmporteerd is in &os; en is
+ 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
+ ofwel in de categorie <literal>bin</literal> ofwel in de
+ categorie <literal>gnu</literal>.</para>
</listitem>
<listitem>
- <para>Individual applications that are not in the base system
- but are instead part of the &os; Ports Collection (category
- <literal>ports</literal>). Most of these applications are
- not written by &os; developers; what &os; provides is merely
- a framework for installing the application. Therefore, you
- should only report a problem to the &os; developers when you
- believe the problem is &os;-specific; otherwise, you should
- report it to the authors of the software.</para>
+ <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 &os;-specifiek is; anders dient u het aan de auteurs
+ van de software te rapporteren.</para>
</listitem>
-
</itemizedlist>
- <para>Then you should ascertain whether or not the problem is
- timely. There are few things
- that will annoy a developer more than receiving a problem report
- about a bug she has already fixed.</para>
+ <para>Daarna dient u vast te stellen of het probleem tijdig 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>If the problem is in the base system, you should first read
- the FAQ section on
- <ulink url="&url.books.faq;/introduction.html#LATEST-VERSION">
- &os; versions</ulink>, if you are not already familiar with
- the topic. It is not possible for &os; to fix problems in
- anything other than certain recent branches of the base system,
- so filing a bug report about an older version will probably
- only result in a developer advising you to upgrade to a
- supported version to see if the problem still recurs. The
- Security Officer team maintains the
- <ulink url="&url.base;/security/">list of supported
- versions</ulink>.</para>
+ <para>Als het probleem in het basissysteem zit, dient u eerst het
+ FAQ-gedeelte over <ulink
+ url="&url.books.faq;/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 bugrapport over een oudere
+ versie waarschijnlijk alleen tot het advies van een ontwikkelaar
+ die u adviseert 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>If the problem is in a port, note that you must first
- upgrade to the latest version of the Ports Collection and see
- if the problem still applies. Due to the rapid pace of changes
- in these applications, it is infeasible for &os; to support
- anything other than the absolute latest versions, and problems
- with older version of applications simply cannot be fixed.</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 andere
+ dan de allernieuwste versies te ondersteunen, en problemen met
+ oudere versies van applicaties kunnen simpelweg niet worden
+ opgelost.</para>
</section>
<section id="pr-prep">
More information about the p4-projects
mailing list