From owner-p4-projects@FreeBSD.ORG Fri Dec 19 17:39:09 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 5874F1065696; Fri, 19 Dec 2008 17:39:09 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BD5E1065680 for ; Fri, 19 Dec 2008 17:39:09 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 0A16D8FC08 for ; Fri, 19 Dec 2008 17:39:09 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id mBJHd9LF047358 for ; Fri, 19 Dec 2008 17:39:09 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id mBJHd907047356 for perforce@freebsd.org; Fri, 19 Dec 2008 17:39:09 GMT (envelope-from rene@FreeBSD.org) Date: Fri, 19 Dec 2008 17:39:09 GMT Message-Id: <200812191739.mBJHd907047356@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Cc: Subject: PERFORCE change 155023 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 17:39:09 -0000 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 @@ + + %articles.ent; ]> - -
+
- Writing &os; Problem Reports + Probleemrapporten voor &os; schrijven &tm-attrib.freebsd; @@ -24,15 +25,18 @@ - This article describes how to best formulate and submit a - problem report to the &os; Project. + Dit artikel beschrijft hoe een probleemrapport het beste + geformuleerd en naar het &os; Project verzonden kan + worden. + + Vertaald door door René Ladan. Dag-Erling Smørgrav - Contributed by + Bijgedragen door @@ -42,179 +46,186 @@ - problem reports + probleemrapporten
- Introduction + Introductie - 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 - not a bug or bogus PR. 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. + 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 geen bug of fout + PR. 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. - 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. + 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. - Although the primary focus of this article is on &os; - problem reports, most of it should apply quite well to other - software projects. + Hoewel de nadruk van dit artikel ligt op probleemrapporten + voor &os;, zou het meeste ook op andere softwareprojecten van + toepassing moeten zijn. - 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. + 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.
- When to submit a problem report + Wanneer een probleemrapport te versturen - 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 - not 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. + 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 niet 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. - So how do you determine what is a bug and what is not? As a - simple rule of thumb your problem is not a - bug if it can be expressed as a question (usually of the form - How do I do X? or Where can I find - Y?). 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;. + Dus hoe wordt bepaald of iets wel of niet een bug is? Een + eenvoudige vuistregel is dat uw probleem geen + bug is als het als een vraag kan worden uitgedrukt (meestal in de + vorm Hoe doe ik X? of Waar kan ik Y + vinden?). 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. - Some cases where it may be appropriate to submit a problem - report about something that is not a bug are: + Enkele gevallen waar het juist kan zijn om een probleemrapport + in te sturen over iets dat geen bug is zijn: - Requests for feature enhancements. It is generally a - good idea to air these on the mailing lists before - submitting a problem report. + 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. - Notification of updates to externally maintained - software (mainly ports, but also externally maintained base - system components such as BIND or various GNU - utilities). + 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). + + Voor onbeheerde ports (MAINTAINER bevat + ports@FreeBSD.org 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. + + 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. - For unmaintained ports (MAINTAINER contains - ports@FreeBSD.org), 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. - - 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. - - In either case, following the process described in Porter's - Handbook will yield the best results. (You might - also wish to read - Contributing to the FreeBSD Ports Collection.) - + In beide gevallen zal het volgen van het proces zoals + beschreven in het Porters + Handboek tot de beste resultaten leiden. (U bent + misschien ook geïnteresseerd in + Bijdragen aan de &os; Portscollectie.) - 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. + 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. - 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: + 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: - 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 kern); - the binary utilities (bin); the manual - pages and documentation (docs); and - the web pages (www). All bugs in - these areas should be reported to the &os; developers. + 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 kern); de binaire hulpmiddelen + (bin); de handleidingpagina's en + documentatie (docs); en de webpagina's + (www). Alle bugs in deze gebieden dienen + aan de &os;-ontwikkelaars gerapporteerd te worden. - Code in the base system that is written and maintained - by others, and imported into &os; and adapted. Examples - include bind, &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 bin or gnu - categories. + Code in het basissysteem die geschreven is en onderhouden + wordt door anderen, en geïmporteerd is in &os; en is + aangepast. Voorbeelden zijn bind, + &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 bin ofwel in de + categorie gnu. - Individual applications that are not in the base system - but are instead part of the &os; Ports Collection (category - ports). 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. + Individuele applicaties die niet in het basissysteem + zitten maar in plaats daarvan deel zijn van de Portscollectie + van &os; (categorie ports). 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. - - 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. + 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. - If the problem is in the base system, you should first read - the FAQ section on - - &os; versions, 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 - list of supported - versions. + Als het probleem in het basissysteem zit, dient u eerst het + FAQ-gedeelte over + &os;-versies 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 lijst + van ondersteunde versies. - 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. + 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.