Date: Fri, 19 Dec 2008 17:39:09 GMT From: Rene Ladan <rene@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 155023 for review Message-ID: <200812191739.mBJHd907047356@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=155023 Change 155023 by rene@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@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@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">
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812191739.mBJHd907047356>