PERFORCE change 155089 for review
Rene Ladan
rene at FreeBSD.org
Sun Dec 21 08:55:46 PST 2008
http://perforce.freebsd.org/chv.cgi?CH=155089
Change 155089 by rene at 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>
More information about the p4-projects
mailing list