Date: Sun, 21 Dec 2008 16:55:46 GMT From: Rene Ladan <rene@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 155089 for review Message-ID: <200812211655.mBLGtkXF075417@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 @@ </section> <section id="pr-writing"> - <title>Writing the problem report</title> + <title>Het probleemrapport schrijven</title> - <para>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.</para> + <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 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.</para> <section> - <title>Tips and tricks for writing a good problem report</title> + <title>Tips en trucs voor het schrijven van een goed + probleemrapport</title> <itemizedlist> <listitem> - <para><emphasis>Do not leave the <quote>Synopsis</quote> - line empty.</emphasis> The PRs go both onto a mailing list - that goes all over the world (where the <quote>Synopsis</quote> - is used - for the <literal>Subject:</literal> 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.</para> + <para><emphasis>Laat de regel <quote>Synopsis</quote> niet + leeg.</emphasis> De PRs 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 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.</para> </listitem> <listitem> - <para><emphasis>Avoid using a weak <quote>Synopsis</quote> - line.</emphasis> 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 <literal>Synopsis: portupgrade is - broken</literal>, see how much more informative this - seems: <literal>Synopsis: port ports-mgmt/portupgrade - coredumps on -current</literal>. (In the case of ports, - it is especially helpful to have both the category and - portname in the <quote>Synopsis</quote> line.)</para> + <para><emphasis>Voorkom het gebruik van een zwakke + <quote>Synopsis</quote>-regel.</emphasis> 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 + <literal>Synopsis: portupgrade is kapot</literal>, zie + hoeveel informatiever dit lijkt: <literal>Synopsis: port + pors-mgmt/portupgrade dumpt core op -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>If you have a patch, say so.</emphasis> - 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 <literal>[patch]</literal> (including the brackets) at the - beginning of the <quote>Synopsis</quote>. (Although it is - not mandatory to use that exact string, by convention, - that is the one that is used.)</para> + <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 diegene + die gebruikt wordt.)</para> </listitem> <listitem> - <para><emphasis>If you are a maintainer, say so.</emphasis> - If you are maintaining a part of the source code (for - instance, a port), you might consider adding the string - <literal>[maintainer update]</literal> (including the brackets) at the beginning of - your synopsis line, and you definitely should set the - <quote>Class</quote> of - your PR to <literal>maintainer-update</literal>. This way - any committer that handles your PR will not have to check.</para> + <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>Be specific.</emphasis> - The more information you supply about what problem you - are having, the better your chance of getting a response.</para> + <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>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.</para> + <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 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.</para> </listitem> <listitem> - <para>Include which global options you have specified in - your <filename>make.conf</filename>. Note: specifying - <literal>-O2</literal> 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.</para> + <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 + 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.</para> </listitem> <listitem> - <para>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):</para> + <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 uitreksels bij te sluiten + die u relevant acht):</para> <itemizedlist> <listitem> - <para>your kernel configuration (including which - hardware devices you have installed)</para> + <para>uw kernelconfiguratie (inclusief welke + hardware-apparaten u heeft geïnstalleerd)</para> </listitem> <listitem> - <para>whether or not you have debugging options enabled - (such as <literal>WITNESS</literal>), and if so, - whether the problem persists when you change the - sense of that option</para> + <para>of u wel of niet debug-opties aan heeft staan + (zoals <literal>WITNESS</literal>), en zoja, of het + probleem zich blijft voordoen als u de optie + omkeert</para> </listitem> + <listitem> - <para>a backtrace, if one was generated</para> + <para>een backtrace, als er een was gegenereerd</para> </listitem> + <listitem> - <para>the fact that you have read - <filename>src/UPDATING</filename> and that your problem - is not listed there (someone is guaranteed to ask)</para> + <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>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)</para> + <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>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):</para> + <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 uitreksels bij te sluiten + die u relevant acht):</para> <itemizedlist> <listitem> - <para>which ports you have installed</para> + <para>welke ports u heeft geïnstalleerd</para> </listitem> + <listitem> <para>any environment variables that override the defaults in <filename>bsd.port.mk</filename>, such as <makevar>PORTSDIR</makevar></para> + <para>alle omgevingsvariabelen die de standaardwaarden + in <filename>bsd.port.mk</filename> overschrijven, + zoals <makevar>PORTSDIR</makevar></para> </listitem> + <listitem> - <para>the fact that you have read - <filename>ports/UPDATING</filename> and that your problem - is not listed there (someone is guaranteed to ask)</para> + <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>Avoid vague requests for features.</emphasis> - PRs of the form <quote>someone should really implement something - that does so-and-so</quote> 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 <literal>freebsd-questions</literal> - than an entry in the PR database, as discussed above.</para> + <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>Make sure no one else has already submitted - a similar PR.</emphasis> 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 - <ulink url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query"></ulink>. - (Of course, everyone is guilty of forgetting to do this - now and then.)</para> </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>Avoid controversial requests.</emphasis> - 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 <quote>The Right Thing To Do</quote>. As noted above, - a careful search of the mailing lists using the archives - at <ulink url="http://www.FreeBSD.org/search/search.html#mailinglists"></ulink>; - is always good preparation.</para> + <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 aan te leveren, maar + ook een verklaring waarom de patches <quote>Het Juiste Ding + Om Te Doen</quote> zijn. 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>Be polite.</emphasis> - 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.</para> + <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>Before you begin</title> + <title>Voordat u begint</title> - <para>If you are using the &man.send-pr.1; program, make sure your - <envar>VISUAL</envar> (or <envar>EDITOR</envar> if - <envar>VISUAL</envar> is not set) environment variable is set - to something sensible.</para> + <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>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 <quote>Electronic - Mail</quote> chapter of the &os; Handbook at - <ulink url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html"></ulink>.</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>Electronische 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>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.</para> + <para>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.</para> - <para>Similar considerations apply if you are using the - <ulink url="&url.base;/send-pr.html"> web-based - PR submission form</ulink> 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.</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>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 <ulink url="&url.base;/send-pr.html">web form</ulink>.</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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812211655.mBLGtkXF075417>