From 23cba8b041ce1fe59994ad00b19fcc5e5b0a7fed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dag-Erling=20Sm=C3=B8rgrav?= Date: Tue, 4 Feb 2003 23:11:18 +0000 Subject: [PATCH] Whitespace cleanup + use
instead of . Translators can safely ignore this commit. --- .../articles/problem-reports/article.sgml | 298 +++++++++--------- 1 file changed, 149 insertions(+), 149 deletions(-) diff --git a/en_US.ISO8859-1/articles/problem-reports/article.sgml b/en_US.ISO8859-1/articles/problem-reports/article.sgml index c3a9462d66..00abf9b4ed 100644 --- a/en_US.ISO8859-1/articles/problem-reports/article.sgml +++ b/en_US.ISO8859-1/articles/problem-reports/article.sgml @@ -13,7 +13,7 @@ This article describes how to best formulate and submit a - problem report to the FreeBSD Project. + problem report to the FreeBSD Project. @@ -27,7 +27,7 @@ problem reports - +
Introduction One of the most frustrating experiences one can have as a @@ -54,9 +54,9 @@ chronologically, so you should read through the entire document before submitting a problem report, rather than treat it as a step-by-step tutorial. - +
- +
When to submit a problem report There are many types of problems, and not all of them should @@ -87,16 +87,16 @@ - Requests for feature enhancements. It is generally a - good idea to air these on the mailing lists before - submitting a problem report. + Requests for feature enhancements. It is generally a + good idea to air these on the mailing lists before + submitting a problem report. - Notification of updates to externally maintained - software (mainly ports, but also externally maintained base - system components such as BIND or various GNU - utilities). + Notification of updates to externally maintained + software (mainly ports, but also externally maintained base + system components such as BIND or various GNU + utilities). @@ -115,9 +115,9 @@ does mean that the chances of your problem report ever leading to a bug fix are very slim, and you should consider letting the matter drop. - +
- +
Preparations A good rule to follow is to always do a background search @@ -130,34 +130,34 @@ - The FAQ. + The FAQ. - The - mailing - lists—if you are not subscribed, use - the - searchable archives on the FreeBSD web site. If your - problem has not been discussed on the lists, you might try - posting a message about it and waiting a few days to see if - someone can spot something you have overlooked. + The + mailing + lists—if you are not subscribed, use + the + searchable archives on the FreeBSD web site. If your + problem has not been discussed on the lists, you might try + posting a message about it and waiting a few days to see if + someone can spot something you have overlooked. - Optionally, the entire web—use your favorite - search engine to locate any references to your problem. You - may even get hits from archived mailing lists or newsgroups - you did not know of or had not thought to search - through. + Optionally, the entire web—use your favorite + search engine to locate any references to your problem. You + may even get hits from archived mailing lists or newsgroups + you did not know of or had not thought to search + through. - Finally, the FreeBSD PR database. Unless your problem - is recent or obscure, there is a fair chance it has already - been reported. + Finally, the FreeBSD PR database. Unless your problem + is recent or obscure, there is a fair chance it has already + been reported. @@ -180,9 +180,9 @@ submit your problem report, there is a good chance that it will go unnoticed for a while, until someone re-categorizes it. - +
- +
Writing the problem report Now that you have decided that your issue merits a problem @@ -192,58 +192,58 @@ environment variable is set to something sensible, and run &man.send-pr.1;. - +
Attaching patches or files The &man.send-pr.1; program has provisions for attaching - files to a problem report. You can attach as many files as - you want provided that each has a unique base name (i.e. the - name of the file proper, without the path). Just use the - command-line option to specify the names - of the files you wish to attach: + files to a problem report. You can attach as many files as + you want provided that each has a unique base name (i.e. the + name of the file proper, without the path). Just use the + command-line option to specify the names + of the files you wish to attach: &prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors Do not worry about binary files, they will be automatically - encoded so as not to upset your mail agent. + encoded so as not to upset your mail agent. If you attach a patch, make sure you use the - or option to - &man.diff.1; to create a context or unified diff, and make - sure to specify the exact CVS revision numbers of the files - you modified so the developers who read your report will be - able to apply them easily. + or option to + &man.diff.1; to create a context or unified diff, and make + sure to specify the exact CVS revision numbers of the files + you modified so the developers who read your report will be + able to apply them easily. You should also take note that unless you explicitly - specify otherwise in your PR, any patches you submit will be - assumed to be licensed under the same terms as the original - file you modified. - + specify otherwise in your PR, any patches you submit will be + assumed to be licensed under the same terms as the original + file you modified. +
- +
Filling out the template The template consists of a list of fields, some of which - are pre-filled, and some of which have comments explaining - their purpose or listing acceptable values. Do not worry - about the comments; they will be removed automatically if you - do not modify them or remove them yourself. + are pre-filled, and some of which have comments explaining + their purpose or listing acceptable values. Do not worry + about the comments; they will be removed automatically if you + do not modify them or remove them yourself. At the top of the template, below the - SEND-PR: lines, are the email headers. You - do not normally need to modify these, unless you are sending - the problem report from a machine or account that can send but - not receive mail, in which case you will want to set the - From: and Reply-To: to - your real email address. You may also want to send yourself - (or someone else) a carbon copy of the problem report by - adding one or more email addresses to the - Cc: header. + SEND-PR: lines, are the email headers. You + do not normally need to modify these, unless you are sending + the problem report from a machine or account that can send but + not receive mail, in which case you will want to set the + From: and Reply-To: to + your real email address. You may also want to send yourself + (or someone else) a carbon copy of the problem report by + adding one or more email addresses to the + Cc: header. Next comes a series of single-line fields: - + Submitter-Id: Do not change this. The default value of current-users is correct, even if you run FreeBSD-STABLE. @@ -251,9 +251,9 @@ Originator: This is normally - prefilled with the gecos field of the currently logged-in - user. Please specify your real name, optionally followed - by your email address in angle brackets. + prefilled with the gecos field of the currently logged-in + user. Please specify your real name, optionally followed + by your email address in angle brackets. @@ -264,40 +264,40 @@ Confidential: This is prefilled - to no, changing it makes no sense as - there is no such thing as a confidential FreeBSD problem - report—the PR database is distributed worldwide by - CVSup. + to no, changing it makes no sense as + there is no such thing as a confidential FreeBSD problem + report—the PR database is distributed worldwide by + CVSup. Synopsis: Fill this out with a - short and accurate description of the problem. The - synopsis is used as the subject of the problem report - email, and is used in problem report listings and - summaries; problem reports with obscure synopses tend to - get ignored. + short and accurate description of the problem. The + synopsis is used as the subject of the problem report + email, and is used in problem report listings and + summaries; problem reports with obscure synopses tend to + get ignored. If your problem report includes a patch, please have - the synopsis start with [PATCH]. + the synopsis start with [PATCH]. Severity: One of - non-critical, - serious or - critical. Do not overreact; refrain - from labeling your problem critical - unless it really is (e.g. root exploit, easily - reproducible panic). Developers tend to ignore this and - the next field, precisely because problem report - submitters tend to overrate their problems. + non-critical, + serious or + critical. Do not overreact; refrain + from labeling your problem critical + unless it really is (e.g. root exploit, easily + reproducible panic). Developers tend to ignore this and + the next field, precisely because problem report + submitters tend to overrate their problems. Priority: One of - low, medium or - high. See above. + low, medium or + high. See above. @@ -306,37 +306,37 @@ advocacy: problems relating to - FreeBSD's public image. Rarely used. + FreeBSD's public image. Rarely used. alpha: problems specific to the - Alpha platform. + Alpha platform. bin: problems with userland - programs in the base system. + programs in the base system. conf: problems with - configuration files, default values etc. + configuration files, default values etc. docs: problems with manual pages - or on-line documentation. + or on-line documentation. gnu: problems with GNU software - such as &man.gcc.1; or &man.grep.1;. + such as &man.gcc.1; or &man.grep.1;. i386: problems specific to the - i386 platform. + i386 platform. @@ -351,27 +351,27 @@ kern: problems with - kernel. + kernel. misc: anything that does not fit - in any of the other categories. + in any of the other categories. - + ports: problems relating to the - ports tree. + ports tree. - + powerpc: problems specific to the - PowerPC platform. + PowerPC platform. sparc64: problems specific to the - SPARC platform. + SPARC platform. @@ -385,35 +385,35 @@ - + Class: Choose one of the following: - + sw-bug: software bugs. - + doc-bug: errors in - documentation. + documentation. - + change-request: requests for - additional features or changes in existing - features. + additional features or changes in existing + features. - + update: updates to ports or - other contributed software. + other contributed software. - + maintainer-update: updates to - ports for which you are the maintainer. + ports for which you are the maintainer. @@ -430,17 +430,17 @@ Finally, there is a series of multi-line fields: - + Environment: This should - describe, as accurately as possible, the environment in - which the problem has been observed. This includes the - operating system version, the version of the specific - program or file that contains the problem, and any other - relevant items such as system configuration, other - installed software that influences the problem, - etc.—quite simply everything a developer needs to - know to reconstruct the environment in which the problem - occurs. + describe, as accurately as possible, the environment in + which the problem has been observed. This includes the + operating system version, the version of the specific + program or file that contains the problem, and any other + relevant items such as system configuration, other + installed software that influences the problem, + etc.—quite simply everything a developer needs to + know to reconstruct the environment in which the problem + occurs. @@ -466,33 +466,33 @@ leave this field blank than to speculate. - +
- +
Sending off the problem report Once you are done filling out the template, have saved it, - and exit your editor, &man.send-pr.1; will prompt you with - s)end, e)dit or a)bort?. You can then hit - s to go ahead and submit the problem report, - e to restart the editor and make - further modifications, or a to abort. - If you choose the latter, your problem report will remain on - disk (&man.send-pr.1; will tell you the filename before it - terminates), so you can edit it at your leisure, or maybe - transfer it to a system with better net connectivity, before - sending it with the to - &man.send-pr.1;: + and exit your editor, &man.send-pr.1; will prompt you with + s)end, e)dit or a)bort?. You can then hit + s to go ahead and submit the problem report, + e to restart the editor and make + further modifications, or a to abort. + If you choose the latter, your problem report will remain on + disk (&man.send-pr.1; will tell you the filename before it + terminates), so you can edit it at your leisure, or maybe + transfer it to a system with better net connectivity, before + sending it with the to + &man.send-pr.1;: &prompt.user; send-pr -f ~/my-problem-report This will read the specified file, validate the contents, - strip comments and send it off. - + strip comments and send it off. +
- +
- +
Follow-up Once your problem report has been filed, you will receive a @@ -516,9 +516,9 @@ gone away, just send a follow-up (in the manner prescribed above) saying that the problem report can be closed, and, if possible, explaining how or when the problem was fixed. - +
- +
Further Reading This is a list of resources relevant to the proper writing @@ -526,19 +526,19 @@ - How to Report Bugs Effectively—an excellent essay by Simon G. Tatham on composing useful (non-FreeBSD-specific) problem reports. - Problem - Report Handling Guidelines—valuable insight - into how problem reports are handled by the FreeBSD - developers. + Problem + Report Handling Guidelines—valuable insight + into how problem reports are handled by the FreeBSD + developers. - +