gnats 4.1.0-3 / usr / share / doc / gnats / gnats / Helpful-hints.html

This file is indexed.

/usr/share/doc/gnats/gnats/Helpful-hints.html is in gnats 4.1.0-3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below. 

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Keeping Track: Helpful hints</title>

<meta name="description" content="Keeping Track: Helpful hints">
<meta name="keywords" content="Keeping Track: Helpful hints">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="Index.html#Index" rel="index" title="Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="send_002dpr.html#send_002dpr" rel="up" title="send-pr">
<link href="edit_002dpr.html#edit_002dpr" rel="next" title="edit-pr">
<link href="Submitting-via-e_002dmail.html#Submitting-via-e_002dmail" rel="prev" title="Submitting via e-mail">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
div.smalllisp {margin-left: 3.2em}
kbd {font-style:oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>


</head>

<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Helpful-hints"></a>
<div class="header">
<p>
Previous: <a href="Submitting-via-e_002dmail.html#Submitting-via-e_002dmail" accesskey="p" rel="prev">Submitting via e-mail</a>, Up: <a href="send_002dpr.html#send_002dpr" accesskey="u" rel="up">send-pr</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<a name="Helpful-hints-1"></a>
<h4 class="subsection">2.2.5 Helpful hints</h4>
<a name="index-helpful-hints"></a>
<a name="index-Using-and-Porting-GNU-CC"></a>
<a name="index-effective-problem-reporting"></a>
<a name="index-kinds-of-helpful-information"></a>
<a name="index-information-to-submit"></a>
<a name="index-Report-all-the-facts_0021"></a>

<p>There is no orthodox standard for submitting effective bug reports,
though you might do well to consult the section on submitting bugs for
<small>GNU</small> <code>gcc</code> in <a href="http://gcc.gnu.org/onlinedocs/gcc/Bugs.html#Bugs">Reporting Bugs</a> in <cite>Using and
Porting GNU CC</cite>, by Richard Stallman.  This section contains
instructions on what kinds of information to include and what kinds of
mistakes to avoid.
</p>
<p>In general, common sense (assuming such an animal exists) dictates the
kind of information that would be most helpful in tracking down and
resolving problems in software.  
</p><ul>
<li> Include anything <em>you</em> would want to know if you were looking at
the report from the other end.  There&rsquo;s no need to include every minute
detail about your environment, although anything that might be different
from someone else&rsquo;s environment should be included (your path, for
instance).

</li><li> Narratives are often useful, given a certain degree of restraint.  If a
person responsible for a bug can see that A was executed, and then B and
then C, knowing that sequence of events might trigger the realization of
an intermediate step that was missing, or an extra step that might have
changed the environment enough to cause a visible problem.  Again,
restraint is always in order (&ldquo;I set the build running, went to get a
cup of coffee (Columbian, cream but no sugar), talked to Sheila on the
phone, and then THIS happened&hellip;&rdquo;) but be sure to include anything
relevant.

</li><li> Richard Stallman writes, &ldquo;The fundamental principle of reporting bugs
usefully is this: <strong>report all the facts</strong>.  If you are not sure
whether to state a fact or leave it out, state it!&rdquo;  This holds true
across all problem reporting systems, for computer software or social
injustice or motorcycle maintenance.  It is especially important in the
software field due to the major differences seemingly insignificant
changes can make (a changed variable, a missing semicolon, etc.).

</li><li> Submit only <em>one</em> problem with each Problem Report.  If you have
multiple problems, use multiple PRs.  This aids in tracking each problem
and also in analyzing the problems associated with a given program.

</li><li> It never hurts to do a little research to find out if the bug you&rsquo;ve
found has already been reported.  Most software releases contain lists
of known bugs in the Release Notes which come with the software; see
your system administrator if you don&rsquo;t have a copy of these.

</li><li> The more closely a PR adheres to the standard format, the less
interaction is required by a database administrator to route the
information to the proper place.  Keep in mind that anything that
requires human interaction also requires time that might be better spent
in actually fixing the problem.  It is therefore in everyone&rsquo;s best
interest that the information contained in a PR be as correct as
possible (in both format and content) at the time of submission.
</li></ul>

<hr>
<div class="header">
<p>
Previous: <a href="Submitting-via-e_002dmail.html#Submitting-via-e_002dmail" accesskey="p" rel="prev">Submitting via e-mail</a>, Up: <a href="send_002dpr.html#send_002dpr" accesskey="u" rel="up">send-pr</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>



</body>
</html>

APT Browse - Built by Thomas Orozco.