This file is indexed.

/etc/debbugs/html/Developer.html.in is in debbugs 2.4.1ubuntu1.

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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
$gDeveloperHtml = <<HTML_END
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
  <title>$gProject - Developers' information</title>
  <link rev="made" href="mailto:$gMaintainerEmail">
</head>
<body>

<h1><A name="developers">Developers' information regarding the $gBug processing system</a></h1>

<p>Initially, a $gBug report is submitted by a user as an ordinary mail
message to <code>submit\@$gEmailDomain</code>.  This will then be
given a number, acknowledged to the user, and forwarded to a mailing 
list (if configured).  If the submitter included a <code>Package</code>
line listing a package with a known maintainer the maintainer will get
a copy too.

<p>The <code>Subject</code> line will have
<code>$gBug#</code><var>nnn</var><code>:</code> added, and the
<code>Reply-To</code> will be set to include both the submitter of the
report and <var>nnn</var><code>\@$gEmailDomain</code>.

<h2>Closing $gBug reports</h2>

<p>A developer who receives a $gBug from the tracking system, or sees it on
the mailing list, and takes responsibility for it should hit Reply in
their favourite mailreader,
and then edit the <code>To</code> field to say
<var>nnn</var><code>-done\@$gEmailDomain</code> instead of
<var>nnn</var><code>\@$gEmailDomain</code>
(<var>nnn</var><code>-close</code> is provided as an alias for
<var>nnn</var><code>-done</code>).

<p>The address of the original submitter of the $gBug report will be
included in the default <code>To</code> field, because the $gBug system
included it in the <code>Reply-To</code>.

<p>`Done' messages are automatically forwarded to the <code>$gDoneList</code>
mailing list, if the mailing list has been set up.

<p>The person closing the $gBug and the person who submitted it will each
get a notification about the change in status of the report.

<h2>Followup messages</h2>

<p>If a developer wishes to reply to a $gBug report they may simply reply
to the message (that will <b>not</b> mark the bug as done). Their reply will
(by default, if they respect the Reply-To: header) go to
<var>nnn</var><code>\@$gEmailDomain</code>, and to the original submitter of
the $gBug report (note: this is two distinct addresses). The $gBug tracking
system will receive the message at <var>nnn</var><code>\@$gEmailDomain</code>,
pass it on to the package maintainer, file the reply with the rest of the
logs for that bug report and forward it to a designated mailing list
(<code>$gSubmitList\@$gEmailDomain</code>).

<p>A developer may explicitly mail the bug's submitter with an email to
<var>nnn</var><code>-submitter\@$gEmailDomain</code>.

<p>If you wish to send a followup message which is not appropriate for
any mailing list you can do so by sending it to
<var>nnn</var><code>-quiet\@$gEmailDomain</code> or
<var>nnn</var><code>-maintonly\@$gEmailDomain</code>.
Mail to <var>nnn</var><code>-quiet\@$gEmailDomain</code> is filed in the
$gBug Tracking System but is not delivered to any individuals or mailing
lists. Mail to <var>nnn</var><code>-maintonly\@$gEmailDomain</code> is
filed in the $gBug Tracking System and is delivered only to the maintainer
of the package in question.

<p>Do <em>not</em> use the `reply to all recipients' or `followup'
feature of your mailer unless you intend to edit down the recipients
substantially.  In particular, see that you don't send followup messages
both to <var>nnn</var><code>\@$gEmailDomain</code> and to
<code>submit\@$gEmailDomain</code>, because the $gBug system will then
get two copies of it and each one will be forwarded to the designated
mailing list separately.

<h2><A name="severities">Severity levels</a></h2>

<p>The $gBug system records a severity level with each $gBug report.  This
is set to <code>$gDefaultSeverity</code> by default, but can be overridden
either by supplying a <code>Severity</code> line in the pseudo-header when
the $gBug is submitted (see the
<a href="Reporting.html#pseudoheader">instructions for reporting $gBugs</a>),
or by using the <code>severity</code> command with the
<a href="#requestserv">control request server</a>.
Separate multiple tags with commas, spaces, or both.

<p>The severity levels are:

<dl>
$gHTMLSeverityDesc
</dl>

<H2><a name="tags">Tags for $gBug reports</a></H2>

<p>Each $gBug can have zero or more of a set of given tags. These tags are
displayed in the list of $gBugs when you look at a package's page, and when
you look at the full $gBug log.

<p>Tags can be set by supplying a <code>Tags</code> line in the
pseudo-header when the $gBug is submitted (see the
<a href="Reporting.html#pseudoheader">instructions for reporting $gBugs</a>),
or by using the <code>tags</code> command with the
<a href="#requestserv">control request server</a>.

<p>The current $gBug tags are:

<dl>
$gHTMLTagDesc
</dl>

<h2><A name="forward">Recording that you have passed on a $gBug report</a></h2>

<p>When a developer forwards a $gBug report to the developer of the
upstream source package from which the $gProject package is derived,
they should note this in the $gBug tracking system as follows:

<p>Make sure that the <code>To</code> field of your message to the author
to has only the author(s) address(es) in it; put both the person who
reported the $gBug and
<var>nnn</var><code>-forwarded\@$gEmailDomain</code> in the
<code>CC</code> field.

<p>Ask the author to preserve the <code>CC</code> to
<var>nnn</var><code>-forwarded\@$gEmailDomain</code> when they reply, so that
the $gBug tracking system will file their reply with the original
report.

<p>When the $gBug tracking system gets a message at
<var>nnn</var><code>-forwarded</code> it will mark the relevant $gBug as
having been forwarded to the address(es) in the <code>To</code> field
of the message it gets, if the $gBug is not already marked as forwarded.

<p>You can also manipulate the `forwarded to' information by sending
messages to <a href="server-control.html"><code>control\@$gEmailDomain</code></a>.

<h2>Summary postings</h2>

<p>Every Friday, a list of outstanding $gBug reports is posted to a summary
mailing list (if set up), sorted by age of report. Every Tuesday, a list of
$gBug reports that have gone unanswered too long is posted, sorted by
package maintainer.

$gBadMaintHtml

<h2><A name="requestserv">Reopening, reassigning and manipulating $gBugs</a></h2>

<p>It is possible to reassign $gBug reports to other packages, to reopen
erroneously-closed ones, to modify the information saying to where, if
anywhere, a $gBug report has been forwarded, to change the severities
and titles of reports and to merge and unmerge $gBug reports.  This is
done by sending mail to <code>control\@$gEmailDomain</code>.

<p>The <a href="server-control.html">format of these messages</a> is
described in another document available on the World Wide Web or in
the file <code>bug-maint-mailcontrol.txt</code>.  A plain text version
can also be obtained by mailing the word <code>help</code> to the
server at the address above.

<h2>More-or-less obsolete subject-scanning feature</h2>

<!-- (this is likely to be removed the next version?) -->

<p>Messages that arrive at <code>submit</code> or <code>$gBugs</code> whose
Subject starts <code>Bug#</code><var>nnn</var> will be treated as
having been sent to <var>nnn</var><code>\@$gEmailDomain</code>.  This is both
for backwards compatibility with mail forwarded from the old
addresses, and to catch followup mail sent to <code>submit</code> by
mistake (for example, by using reply to all recipients).

<p>A similar scheme operates for <code>maintonly</code>,
<code>done</code>, <code>quiet</code> and <code>forwarded</code>,
which treat mail arriving with a Subject tag as having been sent to
the corresponding <var>nnn-whatever</var><code>\@$gEmailDomain</code> address.

<p>Messages arriving at plain <code>forwarded</code> and
<code>done</code> - ie, with no $gBug report number in the address - and
without a $gBug number in the Subject will be filed under `junk' and
kept for a few weeks, but otherwise ignored.

<hr>

<p>Other pages:
<ul>
  <li><a href="./">$gBug tracking system main contents page.</a>
  <li><a href="Reporting.html">Instructions for reporting $gBugs.</a>
  <li><a href="Access.html">Accessing the $gBug tracking logs other than by WWW.</a>
  <li><a href="server-refcard.html">Mailservers' reference card.</a>
  <li><a href="db/ix/full.html">Full list of outstanding and recent $gBug reports.</a>
  <li><a href="db/ix/packages.html">Packages with $gBug reports.</a>
  <li><a href="db/ix/maintainers.html">Maintainers of packages with $gBug reports.</a>
$gHTMLOtherPageList
</ul>

$gHTMLTail

HTML_END