From owner-p4-projects@FreeBSD.ORG Sun Dec 21 16:55:46 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A62381065673; Sun, 21 Dec 2008 16:55:46 +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 4D13F106564A for ; Sun, 21 Dec 2008 16:55:46 +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 3A0F18FC18 for ; Sun, 21 Dec 2008 16:55:46 +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 mBLGtk2r075419 for ; Sun, 21 Dec 2008 16:55:46 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id mBLGtkXF075417 for perforce@freebsd.org; Sun, 21 Dec 2008 16:55:46 GMT (envelope-from rene@FreeBSD.org) Date: Sun, 21 Dec 2008 16:55:46 GMT Message-Id: <200812211655.mBLGtkXF075417@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 155089 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: Sun, 21 Dec 2008 16:55:46 -0000 http://perforce.freebsd.org/chv.cgi?CH=155089 Change 155089 by rene@rene_self on 2008/12/21 16:55:27 Translated 44% of problem-reports article. Affected files ... .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#5 edit Differences ... ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#5 (text+ko) ==== @@ -312,242 +312,265 @@
- Writing the problem report + Het probleemrapport schrijven - Now that you have decided that your issue merits a problem - report, and that it is a &os; problem, it is time to write - the actual problem report. Before we get into the mechanics - of the program used to generate and submit PRs, here are some - tips and tricks to help make sure that your PR will be most - effective. + 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 PRs 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.
- Tips and tricks for writing a good problem report + Tips en trucs voor het schrijven van een goed + probleemrapport - Do not leave the Synopsis - line empty. The PRs go both onto a mailing list - that goes all over the world (where the Synopsis - is used - for the Subject: line), but also into a - database. Anyone who comes along later and browses the - database by synopsis, and finds a PR with a blank subject - line, tends just to skip over it. Remember that PRs stay - in this database until they are closed by someone; an - anonymous one will usually just disappear in the - noise. + Laat de regel Synopsis niet + leeg. De PRs gaan zowel naar een mailinglijst + die over de gehele wereld wordt verspreid (waar de + Synopsis wordt gebruikt voor de + Onderwerp:-regel), als in een database. + Iedereen die later de database op onderwerp doorzoekt, en + een PR met een lege onderwerpsregel aantreft, zal het + waarschijnlijk gewoon overslaan. Onthoud dat PRs in deze + database blijven staan totdat iemand ze sluit; een anoniem + PR zal slechts in de massa opgaan. - Avoid using a weak Synopsis - line. You should not assume that anyone reading - your PR has any context for your submission, so the more - you provide, the better. For instance, what part of the - system does the problem apply to? Do you only see the - problem while installing, or while running? To - illustrate, instead of Synopsis: portupgrade is - broken, see how much more informative this - seems: Synopsis: port ports-mgmt/portupgrade - coredumps on -current. (In the case of ports, - it is especially helpful to have both the category and - portname in the Synopsis line.) + Voorkom het gebruik van een zwakke + Synopsis-regel. U mag niet + aannemen dat iemand die uw PR leest enige context van uw + inzending heeft, dus hoe 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 + Synopsis: portupgrade is kapot, zie + hoeveel informatiever dit lijkt: Synopsis: port + pors-mgmt/portupgrade dumpt core op -current. + (In het geval van ports is het bijzonder behulpzaam om zowel + de categorie als de portnaam in de + Synopsis-regel te vermelden.) - If you have a patch, say so. - A PR with a patch included is much more likely to be - looked at than one without. If you are including one, - put the string [patch] (including the brackets) at the - beginning of the Synopsis. (Although it is - not mandatory to use that exact string, by convention, - that is the one that is used.) + Als u een patch heeft, zeg dat dan. + 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 [patch] + (inclusief de haken) aan het begin van de + Synopsis. (Alhoewel het niet verplicht is om + die exacte tekst te gebruiken, is dat per conventie diegene + die gebruikt wordt.) - If you are a maintainer, say so. - If you are maintaining a part of the source code (for - instance, a port), you might consider adding the string - [maintainer update] (including the brackets) at the beginning of - your synopsis line, and you definitely should set the - Class of - your PR to maintainer-update. This way - any committer that handles your PR will not have to check. + Als u een onderhouder bent, zeg dat + dan. Als u een deel van de broncode onderhoudt + (bijvoorbeeld een port), kunt u overwegen om de tekst + [maintainer update] (inclusief de haken) + aan het begin van de onderwerpsregel te plaatsen, en dient u + zeker de Class van uw PR op + maintainer-update te zetten. Op deze + manier hoeft de committer die uw PR behandelt dit niet te + controleren. - Be specific. - The more information you supply about what problem you - are having, the better your chance of getting a response. + Ben specifiek. Des te meer + informatie u aanlevert over wat voor probleem u heeft, des + te groter is de kans dat u een antwoord krijgt. - Include the version of &os; you are running (there - is a place to put that, see below) and on which architecture. - You should include whether you are running from a release - (e.g. from a CDROM or download), or from - a system maintained by &man.cvsup.1; (and, if so, how - recently you updated). If you are tracking the - &os.current; branch, that is the very first thing someone - will ask, because fixes (especially for high-profile - problems) tend to get committed very quickly, and - &os.current; users are expected to keep up. + 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 van een uitgave draait + (bijvoorbeeld een CD-ROM of een download), of van een + systeem dat met &man.cvsup.1; wordt onderhouden (en + zoja, hoe recentelijk u heeft bijgewerkt). Als u de + &os.current;-tak 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. - Include which global options you have specified in - your make.conf. Note: specifying - -O2 and above to &man.gcc.1; is - known to be buggy in many situations. While the - &os; developers will accept patches, they are - generally unwilling to investigate such issues due - to simple lack of time and volunteers, and may - instead respond that this just is not supported. + Vermeld welke globale opties u in uw + make.conf heeft gespecificeerd. + Noot: het specificeren van -O2 en + hoger aan &man.gcc.1; staat in veel situaties als + buggevoelig bekend. Hoewel de &os;-ontwikkelaar 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. - If this is a kernel problem, then be prepared to - supply the following information. (You do not - have to include these by default, which only tends to - fill up the database, but you should include excerpts - that you think might be relevant): + 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 uitreksels bij te sluiten + die u relevant acht): - your kernel configuration (including which - hardware devices you have installed) + uw kernelconfiguratie (inclusief welke + hardware-apparaten u heeft geïnstalleerd) - whether or not you have debugging options enabled - (such as WITNESS), and if so, - whether the problem persists when you change the - sense of that option + of u wel of niet debug-opties aan heeft staan + (zoals WITNESS), en zoja, of het + probleem zich blijft voordoen als u de optie + omkeert + - a backtrace, if one was generated + een backtrace, als er een was gegenereerd + - the fact that you have read - src/UPDATING and that your problem - is not listed there (someone is guaranteed to ask) + het feit dat u + /usr/src/UPDATING heeft + gelezen en dat uw probleem daar niet staat vermeld + (iemand gaat er geheid naar vragen) + - whether or not you can run any other kernel as - a fallback (this is to rule out hardware-related - issues such as failing disks and overheating CPUs, - which can masquerade as kernel problems) + 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) - If this is a ports problem, then be prepared to - supply the following information. (You do not - have to include these by default, which only tends to - fill up the database, but you should include excerpts - that you think might be relevant): + 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 uitreksels bij te sluiten + die u relevant acht): - which ports you have installed + welke ports u heeft geïnstalleerd + any environment variables that override the defaults in bsd.port.mk, such as PORTSDIR + alle omgevingsvariabelen die de standaardwaarden + in bsd.port.mk overschrijven, + zoals PORTSDIR + - the fact that you have read - ports/UPDATING and that your problem - is not listed there (someone is guaranteed to ask) + het feit dat u + /usr/ports/UPDATING heeft + gelezen en dat uw probleem daar niet staat vermeld + (iemand gaat er geheid naar vragen) - - - Avoid vague requests for features. - PRs of the form someone should really implement something - that does so-and-so are less likely to get results than - very specific requests. Remember, the source is available - to everyone, so if you want a feature, the best way to - ensure it being included is to get to work! Also consider - the fact that many things like this would make a better - topic for discussion on freebsd-questions - than an entry in the PR database, as discussed above. + Voorkom vage verzoeken voor + mogelijkheden. PR's van de vorm iemand + moet echt iets dat zus-en-zo doet implementeren + 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 freebsd-questions besproken + kunnen worden dan als een regel in de PR-database, zoals + hierboven besproken. - Make sure no one else has already submitted - a similar PR. Although this has already been - mentioned above, it bears repeating here. It only take a - minute or two to use the web-based search engine at - . - (Of course, everyone is guilty of forgetting to do this - now and then.) + Verzeker u ervan dat niemand anders reeds een + soortgelijk PR heeft ingestuurd. Alhoewel dit al + hierboven genoemd is, is het het herhalen hier waard. Het + duurt slechts een minuut of twee om de webgebaseerde + zoekmachine op + te gebruiken. (Natuurlijk vergeet iedereen dit zo + nu en dan.) + - Avoid controversial requests. - If your PR addresses an area that has been controversial - in the past, you should probably be prepared to not only - offer patches, but also justification for why the patches - are The Right Thing To Do. As noted above, - a careful search of the mailing lists using the archives - at - is always good preparation. + Voorkom controversiële + verzoeken. Als uw PR een gebied behandelt dat in + het verleden controversieel was, dient u waarschijnlijk + bereid te zijn om niet alleen patches aan te leveren, maar + ook een verklaring waarom de patches Het Juiste Ding + Om Te Doen zijn. Zoals hierboven vermeld, is het + zorgvuldig doorzoeken van de mailinglijsten door gebruik te + maken van de archieven op + altijd een goede voorbereiding. - Be polite. - Almost anyone who would potentially work on your PR is a - volunteer. No one likes to be told that they have to do - something when they are already doing it for some - motivation other than monetary gain. This is a good thing - to keep in mind at all times on Open Source - projects. + Ben beleefd. 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.
- Before you begin + Voordat u begint - If you are using the &man.send-pr.1; program, make sure your - VISUAL (or EDITOR if - VISUAL is not set) environment variable is set - to something sensible. + Als u het programma &man.send-pr.1; gebruikt, zorg er dan + voor dat uw omgevingsvariabele VISUAL (of + EDITOR als VISUAL niet is + ingesteld) op iets zinnigs is ingesteld. - You should also make sure that mail delivery works fine. - &man.send-pr.1; uses mail messages for the submission and - tracking of problem reports. If you cannot post mail messages - from the machine you are running &man.send-pr.1; on, your - problem report will not reach the GNATS database. For details - on the setup of mail on &os;, see the Electronic - Mail chapter of the &os; Handbook at - . + 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 Electronische post van het &os; + Handboek op + . - Make sure that your mailer will not mangle the message on - its way to GNATS. In particular, if your mailer automatically - breaks lines, changes tabs to spaces, or escapes newline - characters, any patch that you submit will be rendered - unusable. For the text sections, however, we request that - you insert manual linebreaks somewhere around 70 characters, - so that the web display of the PR will be readable. + Verzeker u ervan dat uw mailprogramma het bericht onderweg + naar GNATS niet vermangelt. In het bijzonder, als uw mailer + automatisch regels afbreekt, tabs in spaties verandert, of + nieuwe-regel-tekens ontvlucht, zal elke patch die u instuurt + onbruikbaar worden. Voor de tekstgedeelten vragen wij u echer + om handmatig regels rond de 70 tekens af te breken, zodat de + webversie van het PR leesbaar is. - Similar considerations apply if you are using the - web-based - PR submission form instead of &man.send-pr.1;. Note that - cut-and-paste operations can have their own side-effects on - text formatting. In certain cases it may be necessary to use - &man.uuencode.1; to ensure that patches arrive unmodified. + Dezelfde soort overwegingen gelden als u het webgebaseerde + PR-instuurformulier 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. - Finally, if your submission will be lengthy, you should - to prepare your work offline so that nothing will be lost in - case there is a problem submitting it. This can especially be a - problem with the web form. + 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 webformulier.