зеркало из https://github.com/mozilla/gecko-dev.git
Bug 170213 - make static HTML files into page.cgi pages. This does votehelp.html (-> id=voting.html), bug_status.html (-> id=fields.html) and bugwritinghelp.html (-> id=bug-writing.html). Patch by gerv; r=kiko, a=justdave.
This commit is contained in:
gerv%gerv.net
Родитель
1e5e003141
Коммит
93df2945c9
|
|
@ -137,7 +137,7 @@ sub EmitFormElements ($$$$$$$$)
|
|||
print " <TD><INPUT SIZE=5 MAXLENGTH=5 NAME=\"maxvotesperbug\" VALUE=\"$maxvotesperbug\"></TD>\n";
|
||||
|
||||
print "</TR><TR>\n";
|
||||
print " <TH ALIGN=\"right\">Number of votes a bug in this product needs to automatically get out of the <A HREF=\"bug_status.html#status\">UNCONFIRMED</A> state:</TH>\n";
|
||||
print " <TH ALIGN=\"right\">Number of votes a bug in this product needs to automatically get out of the <A HREF=\"page.cgi?id=fields.html#status\">UNCONFIRMED</A> state:</TH>\n";
|
||||
print " <TD><INPUT SIZE=5 MAXLENGTH=5 NAME=\"votestoconfirm\" VALUE=\"$votestoconfirm\"></TD>\n";
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ for access speed):
|
|||
<td rowspan="2"><tt>UNCO,NEW,...,CLOS,<br>FIX,DUP,...<i>(as first word)</i></tt></td>
|
||||
<td><tt>status</tt></td>
|
||||
<td> </td>
|
||||
<td><a href="bug_status.html">Status</a>
|
||||
<td><a href="page.cgi?id=fields.html#status">Status</a>
|
||||
<i>("bug_status")</i>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -87,35 +87,35 @@ for access speed):
|
|||
<td> </td>
|
||||
<td><tt>resolution</tt></td>
|
||||
<td> </td>
|
||||
<td><a href="bug_status.html">Resolution</a></td>
|
||||
<td><a href="page.cgi?id=fields.html#resolution">Resolution</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td><i>as-is</i></td>
|
||||
<td><tt>platform</tt></td>
|
||||
<td> </td>
|
||||
<td><a href="bug_status.html#rep_platform">Platform</a> <i>("rep_platform")</i></td>
|
||||
<td><a href="page.cgi?id=fields.html#rep_platform">Platform</a> <i>("rep_platform")</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><tt>os</tt></td>
|
||||
<td><tt>opsys</tt></td>
|
||||
<td><a href="bug_status.html#op_sys">OS</a> <i>("op_sys")</i></td>
|
||||
<td><a href="page.cgi?id=fields.html#op_sys">OS</a> <i>("op_sys")</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td><tt>p1,p2</tt> <i>or</i> <tt>p1-2</tt></td>
|
||||
<td><tt>priority</tt></td>
|
||||
<td><tt>pri</tt></td>
|
||||
<td><a href="bug_status.html#priority">Priority</a></td>
|
||||
<td><a href="page.cgi?id=fields.html#priority">Priority</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td><tt>blo,cri,...,enh</tt></td>
|
||||
<td><tt>severity</tt></td>
|
||||
<td><tt>sev</tt></td>
|
||||
<td><a href="bug_status.html#severity">Severity</a> <i>("bug_severity")</i></td>
|
||||
<td><a href="page.cgi?id=fields.html#bug_severity">Severity</a> <i>("bug_severity")</i></td>
|
||||
</tr>
|
||||
|
||||
<!-- People: AssignedTo, Reporter, QA Contact, CC, Added comment -->
|
||||
|
|
@ -126,7 +126,7 @@ for access speed):
|
|||
<td><b>@</b><i>owner</i></td>
|
||||
<td><tt>assignedto</tt></td>
|
||||
<td><tt>assignee, owner</tt></td>
|
||||
<td><a href="bug_status.html#assigned_to">Assignee</a> <i>("assigned_to")</i></td>
|
||||
<td><a href="page.cgi?id=fields.html#assigned_to">Assignee</a> <i>("assigned_to")</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ function set_assign_to() {
|
|||
<tr>
|
||||
<td align="right">
|
||||
<strong>
|
||||
<a href="bug_status.html#assigned_to">Assign To</a>:
|
||||
<a href="page.cgi?id=fields.html#assigned_to">Assign To</a>:
|
||||
</strong>
|
||||
</td>
|
||||
<td colspan="3">
|
||||
|
|
@ -333,7 +333,8 @@ function set_assign_to() {
|
|||
[% IF sel.description %]
|
||||
<td align="right">
|
||||
<strong>
|
||||
<a href="bug_status.html#[% sel.name %]">[% sel.description %]</a>:
|
||||
<a href="page.cgi?id=fields.html#[% sel.name %]">
|
||||
[% sel.description %]</a>:
|
||||
</strong>
|
||||
</td>
|
||||
[% END %]
|
||||
|
|
|
|||
|
|
@ -30,7 +30,8 @@
|
|||
|
||||
[% PROCESS global/variables.none.tmpl %]
|
||||
|
||||
Before reporting [% terms.abug %], please read the <a href="bugwritinghelp.html">
|
||||
Before reporting [% terms.abug %], please read the
|
||||
<a href="page.cgi?id=bug-writing.html">
|
||||
[% terms.bug %] writing guidelines</a>, please look at the list of
|
||||
<a href="duplicates.cgi">most frequently reported [% terms.bugs %]</a>, and please
|
||||
<a href="query.cgi">search</a> for the [% terms.bug %].
|
||||
|
|
|
|||
|
|
@ -205,14 +205,14 @@
|
|||
<tr>
|
||||
<td align="right">
|
||||
<b>
|
||||
<a href="bug_status.html">Status</a>:
|
||||
<a href="page.cgi?id=fields.html#status">Status</a>:
|
||||
</b>
|
||||
</td>
|
||||
<td>[% bug.bug_status FILTER html %]</td>
|
||||
<td> </td>
|
||||
|
||||
<td align="right">
|
||||
<b><a href="bug_status.html#priority">Pr<u>i</u>ority</a>:</b>
|
||||
<b><a href="page.cgi?id=fields.html#priority">Pr<u>i</u>ority</a>:</b>
|
||||
</td>
|
||||
[% PROCESS select selname => "priority" accesskey => "i" %]
|
||||
</tr>
|
||||
|
|
@ -220,7 +220,7 @@
|
|||
<tr>
|
||||
<td align="right">
|
||||
<b>
|
||||
<a href="bug_status.html">Resolution</a>:
|
||||
<a href="page.cgi?id=fields.html#resolution">Resolution</a>:
|
||||
</b>
|
||||
</td>
|
||||
<td>
|
||||
|
|
@ -232,7 +232,7 @@
|
|||
<td> </td>
|
||||
|
||||
<td align="right">
|
||||
<b><a href="bug_status.html#severity">S<u>e</u>verity</a>:</b>
|
||||
<b><a href="page.cgi?id=fields.html#severity">S<u>e</u>verity</a>:</b>
|
||||
</td>
|
||||
[% PROCESS select selname = "bug_severity" accesskey => "e" %]
|
||||
|
||||
|
|
@ -241,7 +241,7 @@
|
|||
<tr>
|
||||
<td align="right">
|
||||
<b>
|
||||
<a href="bug_status.html#assigned_to">Assigned To</a>:
|
||||
<a href="page.cgi?id=fields.html#assigned_to">Assigned To</a>:
|
||||
</b>
|
||||
</td>
|
||||
<td>[% bug.assigned_to.identity FILTER html %]</td>
|
||||
|
|
@ -428,7 +428,7 @@
|
|||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
<a href="votehelp.html">Votes</a>:
|
||||
<a href="page.cgi?id=voting.html">Votes</a>:
|
||||
</th>
|
||||
<td>
|
||||
[% bug.votes %]
|
||||
|
|
|
|||
|
|
@ -59,7 +59,8 @@
|
|||
[% END %]
|
||||
|
||||
<input type="radio" name="knob" value="resolve">
|
||||
Resolve [% terms.bug %], changing <a href="bug_status.html">resolution</a> to
|
||||
Resolve [% terms.bug %], changing
|
||||
<a href="page.cgi?id=fields.html#resolution">resolution</a> to
|
||||
<select name="resolution"
|
||||
onchange="document.changeform.knob[[% knum %]].checked=true">
|
||||
[% FOREACH r = bug.choices.resolution %]
|
||||
|
|
@ -78,7 +79,8 @@
|
|||
[% knum = knum + 1 %]
|
||||
|
||||
<input type="radio" name="knob" value="reassign">
|
||||
<a href="bug_status.html#assigned_to">Reassign</a> [% terms.bug %] to
|
||||
<a href="page.cgi?id=fields.html#assigned_to">Reassign</a>
|
||||
[% terms.bug %] to
|
||||
<input name="assigned_to" size="32"
|
||||
onchange="if ((this.value != '[% bug.assigned_to.email FILTER js %]') &&
|
||||
(this.value != '')) {
|
||||
|
|
|
|||
|
|
@ -141,7 +141,7 @@
|
|||
[% END %]
|
||||
|
||||
<p>
|
||||
<a href="votehelp.html">Help with voting</a>.
|
||||
<a href="page.cgi?id=voting.html">Help with voting</a>.
|
||||
</p>
|
||||
|
||||
[% PROCESS global/footer.html.tmpl %]
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@
|
|||
|
||||
<th>
|
||||
<label for="rep_platform">
|
||||
<a href="bug_status.html#rep_platform">Platform</a>:
|
||||
<a href="page.cgi?id=fields.html#rep_platform">Platform</a>:
|
||||
</label>
|
||||
</th>
|
||||
<td>
|
||||
|
|
@ -80,7 +80,7 @@
|
|||
|
||||
<th>
|
||||
<label for="priority">
|
||||
<a href="bug_status.html#priority">Priority</a>:
|
||||
<a href="page.cgi?id=fields.html#priority">Priority</a>:
|
||||
</label>
|
||||
</th>
|
||||
<td>
|
||||
|
|
@ -99,7 +99,7 @@
|
|||
|
||||
<th>
|
||||
<label for="bug_severity">
|
||||
<a href="bug_status.html#severity">Severity</a>:
|
||||
<a href="page.cgi?id=fields.html#severity">Severity</a>:
|
||||
</label>
|
||||
</th>
|
||||
<td>
|
||||
|
|
@ -266,7 +266,7 @@
|
|||
[% knum = knum + 1 %]
|
||||
<input id="knob-resolve" type="radio" name="knob" value="resolve">
|
||||
<label for="knob-resolve">
|
||||
Resolve [% terms.bugs %], changing <a href="bug_status.html">resolution</a> to
|
||||
Resolve [% terms.bugs %], changing <a href="page.cgi?id=fields.html#resolution">resolution</a> to
|
||||
</label>
|
||||
<select name="resolution" onchange="document.forms.changeform.knob[[% knum %]].checked=true">
|
||||
[% FOREACH resolution = resolutions %]
|
||||
|
|
@ -300,7 +300,7 @@
|
|||
|
||||
[% knum = knum + 1 %]
|
||||
<input id="knob-reassign" type="radio" name="knob" value="reassign">
|
||||
<label for="knob-reassign"><a href="bug_status.html#assigned_to">
|
||||
<label for="knob-reassign"><a href="page.cgi?id=fields.html#assigned_to">
|
||||
Reassign</a> [% terms.bugs %] to
|
||||
</label>
|
||||
<input name="assigned_to"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,390 @@
|
|||
[%# 1.0@bugzilla.org %]
|
||||
[%# The contents of this file are subject to the Mozilla Public
|
||||
# License Version 1.1 (the "License"); you may not use this file
|
||||
# except in compliance with the License. You may obtain a copy of
|
||||
# the License at http://www.mozilla.org/MPL/
|
||||
#
|
||||
# Software distributed under the License is distributed on an "AS
|
||||
# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
|
||||
# implied. See the License for the specific language governing
|
||||
# rights and limitations under the License.
|
||||
#
|
||||
# The Original Code is the Bugzilla Bug Tracking System.
|
||||
#
|
||||
# The Initial Developer of the Original Code is Netscape Communications
|
||||
# Corporation. Portions created by Netscape are
|
||||
# Copyright (C) 1998 Netscape Communications Corporation. All
|
||||
# Rights Reserved.
|
||||
#
|
||||
# Contributor(s): Eli Goldberg <eli@prometheus-music.com>
|
||||
# Gervase Markham <gerv@gerv.net>
|
||||
# Claudius Gayle
|
||||
# Peter Mock
|
||||
# Chris Pratt
|
||||
# Tom Schutter
|
||||
# Chris Yeh
|
||||
#%]
|
||||
|
||||
[% PROCESS global/variables.none.tmpl %]
|
||||
[% INCLUDE global/header.html.tmpl title = "$terms.Bug Writing Guidelines" %]
|
||||
|
||||
<h3>Why You Should Read This</h3>
|
||||
|
||||
<blockquote>
|
||||
<p>Simply put, the more effectively you report a [% terms.bug %], the more
|
||||
likely an
|
||||
engineer will actually fix it.</p>
|
||||
|
||||
<p>These guidelines are a general tutorial to teach novice and
|
||||
intermediate [% terms.bug %] reporters how to compose effective
|
||||
[% terms.bug %] reports. Not
|
||||
every sentence may precisely apply to your software project.</p>
|
||||
</blockquote>
|
||||
|
||||
<h3>How to Write a Useful [% terms.Bug %] Report</h3>
|
||||
|
||||
<blockquote>
|
||||
<p>Useful [% terms.bug %] reports are ones that get [% terms.bugs %] fixed.
|
||||
A useful [% terms.bug %] report normally has two qualities:</p>
|
||||
|
||||
<ol>
|
||||
<li><b>Reproducible.</b> If an engineer can't see the [% terms.bug %]
|
||||
herself to prove that it exists, she'll probably stamp your [% terms.bug %]
|
||||
report "WORKSFORME" or "INVALID" and move on to the next [% terms.bug %].
|
||||
Every detail you can provide helps.<br>
|
||||
<br>
|
||||
</li>
|
||||
|
||||
<li><b>Specific.</b> The quicker the engineer can isolate the
|
||||
[% terms.bug %] to a specific area, the more likely she'll expediently
|
||||
fix it. (If a programmer or tester has to decypher a [% terms.bug %],
|
||||
they may spend more time cursing the submitter than solving the
|
||||
problem.)<br>
|
||||
<br>
|
||||
[ <a href="#tips" name="Anchor">Tell Me More</a> ]</li>
|
||||
</ol>
|
||||
|
||||
<p>Let's say the application you're testing is a web browser. You crash
|
||||
at foo.com, and want to write up a [% terms.bug %] report:</p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>BAD:</b> "My browser crashed. I think I was on www.foo.com. I
|
||||
play golf with Bill Gates, so you better fix this problem, or I'll
|
||||
report you to him. By the way, your Back icon looks like a squashed
|
||||
rodent. UGGGLY. And my grandmother's home page is all messed up in your
|
||||
browser. Thx 4 UR help."</p>
|
||||
|
||||
<p><b>GOOD:</b> "I crashed each time I went to www.foo.com, using the
|
||||
2002-02-25 build on a Windows 2000 system. I also rebooted into Linux,
|
||||
and reproduced this problem using the 2002-02-24 Linux build.</p>
|
||||
|
||||
<p>It again crashed each time upon drawing the Foo banner at the top of
|
||||
the page. I broke apart the page, and discovered that the following
|
||||
image link will crash the application reproducibly, unless you remove
|
||||
the "border=0" attribute:</p>
|
||||
|
||||
<p><tt><IMG SRC="http://www.foo.com/images/topics/topicfoos.gif"
|
||||
width="34" height="44" border="0" alt="News"></tt></p>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<h3>How to Enter your Useful [% terms.Bug %] Report
|
||||
into [% terms.Bugzilla %]:</h3>
|
||||
|
||||
<blockquote>
|
||||
<p>Before you enter your [% terms.bug %], use [% terms.Bugzilla %]'s
|
||||
<a href="query.cgi">search page</a> to determine whether the defect
|
||||
you've discovered is a known, already-reported [% terms.bug %]. If
|
||||
your [% terms.bug %] is the 37th duplicate of a known issue,
|
||||
you're more likely to annoy the engineer. (Annoyed engineers fix fewer
|
||||
[% terms.bugs %].)</p>
|
||||
|
||||
<p>Next, be sure to reproduce your [% terms.bug %] using a recent build.
|
||||
Engineers tend to be most interested in problems affecting the code base
|
||||
that they're actively working on. After all, the [% terms.bug %] you're
|
||||
reporting may already be fixed.</p>
|
||||
|
||||
<p>If you've discovered a new [% terms.bug %] using a current build, report
|
||||
it in [% terms.Bugzilla %]:</p>
|
||||
|
||||
<ol>
|
||||
<li>From your [% terms.Bugzilla %] main page, choose
|
||||
"<a href="enter_bug.cgi">Enter a new [% terms.bug %]</a>".</li>
|
||||
|
||||
<li>Select the product that you've found a [% terms.bug %] in.</li>
|
||||
|
||||
<li>Enter your e-mail address, password, and press the "Login" button.
|
||||
(If you don't yet have a password, leave the password field empty, and
|
||||
press the "E-mail me a password" button instead. You'll quickly receive
|
||||
an e-mail message with your password.)</li>
|
||||
</ol>
|
||||
|
||||
<p>Now, fill out the form. Here's what it all means:</p>
|
||||
|
||||
<p><b>Where did you find the [% terms.bug %]?</b></p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>Product: In which product did you find the [% terms.bug %]?</b><br>
|
||||
You just specified this on the last page, so you can't edit it
|
||||
here.</p>
|
||||
|
||||
<p><b>Version: In which product version did you find
|
||||
the [% terms.bug %]?</b><br>
|
||||
(If applicable)</p>
|
||||
|
||||
<p><b>Component: In which component does the [% terms.bug %]
|
||||
exist?</b><br>
|
||||
[% terms.Bugzilla %] requires that you select a component to enter
|
||||
a [% terms.bug %]. (Not sure which to choose? Click on the Component link.
|
||||
You'll see a description of each component, to help you make the best
|
||||
choice.)</p>
|
||||
|
||||
<p><b>OS: On which Operating System (OS) did you find
|
||||
this [% terms.bug %]?</b>
|
||||
(e.g. Linux, Windows 2000, Mac OS 9.)<br>
|
||||
If you know the [% terms.bug %] happens on all OSs, choose 'All'.
|
||||
Otherwise, select the OS that you found the [% terms.bug %] on, or
|
||||
"Other" if your OS isn't listed.</p>
|
||||
</blockquote>
|
||||
|
||||
<p><b>How important is the [% terms.bug %]?</b></p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>Severity: How damaging is the [% terms.bug %]?</b><br>
|
||||
This item defaults to 'normal'. If you're not sure what severity your
|
||||
[% terms.bug %] deserves, click on the Severity link. You'll see a
|
||||
description of each severity rating.<br>
|
||||
</p>
|
||||
</blockquote>
|
||||
|
||||
<p><b>Who will be following up on the [% terms.bug %]?</b></p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>Assigned To: Which engineer should be responsible for fixing
|
||||
this [% terms.bug %]?</b><br>
|
||||
[% terms.Bugzilla %] will automatically assign the [% terms.bug %] to a
|
||||
default engineer upon submitting a [% terms.bug %] report. If you'd prefer
|
||||
to directly assign the [% terms.bug %] to someone else, enter their e-mail
|
||||
address into this field. (To see the list of default engineers for each
|
||||
component, click on the Component link.)</p>
|
||||
|
||||
<p><b>Cc: Who else should receive e-mail updates on changes to this
|
||||
[% terms.bug %]?</b><br>
|
||||
List the full e-mail addresses of other individuals who should receive
|
||||
an e-mail update upon every change to the [% terms.bug %] report. You can
|
||||
enter as many e-mail addresses as you'd like, separated by spaces or
|
||||
commas, as long as those people have [% terms.Bugzilla %] accounts.</p>
|
||||
</blockquote>
|
||||
|
||||
<p><b>What else can you tell the engineer about the [% terms.bug %]?</b></p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>Summary:</b> <b>How would you describe the [% terms.bug %], in
|
||||
approximately 60 or fewer characters?</b><br>
|
||||
A good summary should <b>quickly and uniquely identify a [% terms.bug %]
|
||||
report</b>. Otherwise, an engineer cannot meaningfully identify your
|
||||
[% terms.bug %] by its summary, and will often fail to pay attention to
|
||||
your [% terms.bug %] report when skimming through a 10
|
||||
page [% terms.bug %] list.<br>
|
||||
<br>
|
||||
A useful summary might be "<tt>PCMCIA install fails on Tosh Tecra
|
||||
780DVD w/ 3c589C</tt>". "<tt>Software fails</tt>" or "<tt>install
|
||||
problem</tt>" would be examples of a bad summary.<br>
|
||||
<br>
|
||||
[ <a href="#summary">Tell Me More</a> ]<br>
|
||||
<br>
|
||||
<b>Description:</b><br>
|
||||
Please provide a detailed problem report in this field. Your
|
||||
[% terms.bug %]'s recipients will most likely expect the following
|
||||
information:</p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>Overview Description:</b> More detailed expansion of
|
||||
summary.</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
Drag-selecting any page crashes Mac builds in NSGetFactory
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p><b>Steps to Reproduce:</b> Minimized, easy-to-follow steps that
|
||||
will trigger the [% terms.bug %]. Include any special setup steps.</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
1) View any web page. (I used the default sample page,
|
||||
resource:/res/samples/test0.html)
|
||||
|
||||
2) Drag-select the page. (Specifically, while holding down
|
||||
the mouse button, drag the mouse pointer downwards from any
|
||||
point in the browser's content region to the bottom of the
|
||||
browser's content region.)
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p><b>Actual Results:</b> What the application did after performing
|
||||
the above steps.</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
The application crashed. Stack crawl appended below from MacsBug.
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p><b>Expected Results:</b> What the application should have done,
|
||||
were the [% terms.bug %] not present.</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
The window should scroll downwards. Scrolled content should be selected.
|
||||
(Or, at least, the application should not crash.)
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p><b>Build Date & Platform:</b> Date and platform of the build
|
||||
that you first encountered the [% terms.bug %] in.</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
Build 2002-03-15 on Mac OS 9.0
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p><b>Additional Builds and Platforms:</b> Whether or not
|
||||
the [% terms.bug %] takes place on other platforms (or browsers,
|
||||
if applicable).</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
- Also Occurs On
|
||||
Mozilla (2002-03-15 build on Windows NT 4.0)
|
||||
|
||||
- Doesn't Occur On
|
||||
Mozilla (2002-03-15 build on Red Hat Linux; feature not supported)
|
||||
Internet Explorer 5.0 (shipping build on Windows NT 4.0)
|
||||
Netscape Communicator 4.5 (shipping build on Mac OS 9.0)
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p><b>Additional Information:</b> Any other debugging information.
|
||||
For crashing [% terms.bugs %]:</p>
|
||||
|
||||
<ul>
|
||||
<li><b>Win32:</b> if you receive a Dr. Watson error, please note
|
||||
the type of the crash, and the module that the application crashed
|
||||
in. (e.g. access violation in apprunner.exe)</li>
|
||||
|
||||
<li><b>Mac OS:</b> if you're running MacsBug, please provide the
|
||||
results of a <b>how</b> and an <b>sc</b>:</li>
|
||||
</ul>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
*** MACSBUG STACK CRAWL OF CRASH (Mac OS)
|
||||
Calling chain using A6/R1 links
|
||||
Back chain ISA Caller
|
||||
00000000 PPC 0BA85E74
|
||||
03AEFD80 PPC 0B742248
|
||||
03AEFD30 PPC 0B50FDDC NSGetFactory+027FC
|
||||
PowerPC unmapped memory exception at 0B512BD0 NSGetFactory+055F0
|
||||
</pre>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<p>You're done!<br>
|
||||
<br>
|
||||
After double-checking your entries for any possible errors, press the
|
||||
"Commit" button, and your [% terms.bug %] report will now be in
|
||||
the [% terms.Bugzilla %] database.<br>
|
||||
</p>
|
||||
</blockquote>
|
||||
<hr>
|
||||
|
||||
<h3>More Information on Writing Good [% terms.Bugs %]</h3>
|
||||
|
||||
<blockquote>
|
||||
<p><b><a name="tips"></a> 1. General Tips for a Useful [% terms.Bug %]
|
||||
Report</b></p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>Use an explicit structure, so your [% terms.bug %] reports are easy
|
||||
to skim.</b> [% terms.Bug %] report users often need immediate access to
|
||||
specific sections of your [% terms.bug %]. If your [% terms.Bugzilla %]
|
||||
installation supports the [% terms.Bugzilla %] Helper, use it.</p>
|
||||
|
||||
<p><b>Avoid cuteness if it costs clarity.</b> Nobody will be laughing
|
||||
at your funny [% terms.bug %] title at 3:00 AM when they can't remember how
|
||||
to find your [% terms.bug %].</p>
|
||||
|
||||
<p><b>One [% terms.bug %] per report.</b> Completely different people
|
||||
typically fix, verify, and prioritize different [% terms.bugs %]. If you
|
||||
mix a handful of [% terms.bugs %] into a single report, the right people
|
||||
probably won't discover your [% terms.bugs %] in a timely fashion, or at
|
||||
all. Certain [% terms.bugs %] are also more important than others. It's
|
||||
impossible to prioritize a [% terms.bug %] report when
|
||||
it contains four different issues, all of differing importance.</p>
|
||||
|
||||
<p><b>No [% terms.bug %] is too trivial to report.</b> Unless you're
|
||||
reading the source code, you can't see actual software [% terms.bugs %],
|
||||
like a dangling pointer -- you'll see their visible manifestations, such
|
||||
as the segfault when the application finally crashes. Severe software
|
||||
problems can manifest themselves in superficially trivial ways. File them
|
||||
anyway.<br>
|
||||
</p>
|
||||
</blockquote>
|
||||
|
||||
<p><b><a name="summary"></a>2. How and Why to Write Good [% terms.Bug %]
|
||||
Summaries</b></p>
|
||||
|
||||
<blockquote>
|
||||
<p><b>You want to make a good first impression on the [% terms.bug %]
|
||||
recipient.</b> Just like a New York Times headline guides readers
|
||||
towards a relevant article from dozens of choices, will
|
||||
your [% terms.bug %] summary suggest that your [% terms.bug %] report is
|
||||
worth reading from dozens or hundreds of choices?</p>
|
||||
|
||||
<p>Conversely, a vague [% terms.bug %] summary like <tt>install
|
||||
problem</tt> forces anyone reviewing installation [% terms.bugs %] to waste
|
||||
time opening up your [% terms.bug %] to determine whether it matters.</p>
|
||||
|
||||
<p><b>Your [% terms.bug %] will often be searched by its summary.</b> Just
|
||||
as you'd find web pages with Google by searching by keywords through
|
||||
intuition, so will other people locate your [% terms.bugs %].
|
||||
Descriptive [% terms.bug %] summaries are
|
||||
naturally keyword-rich, and easier to find.</p>
|
||||
|
||||
<p>For example, you'll find a [% terms.bug %] titled "<tt>Dragging icons
|
||||
from List View to gnome-terminal doesn't paste path</tt>" if you search on
|
||||
"List", "terminal", or "path". Those search keywords wouldn't have
|
||||
found a [% terms.bug %] titled "<tt>Dragging icons doesn't paste</tt>".</p>
|
||||
|
||||
<p>Ask yourself, "Would someone understand my [% terms.bug %] from just
|
||||
this summary?" If so, you've written a fine summary.</p>
|
||||
|
||||
<p><b>Don't write titles like these:</b></p>
|
||||
|
||||
<ol>
|
||||
<li>"Can't install" - Why can't you install? What happens when you
|
||||
try to install?</li>
|
||||
|
||||
<li>"Severe Performance Problems" - ...and they occur when you do
|
||||
what?</li>
|
||||
|
||||
<li>"back button does not work" - Ever? At all?</li>
|
||||
</ol>
|
||||
|
||||
<p><b>Good [% terms.bug %] titles:</b></p>
|
||||
|
||||
<ol>
|
||||
<li>"1.0 upgrade installation fails if Mozilla M18 package present" -
|
||||
Explains problem and the context.</li>
|
||||
|
||||
<li>"RPM 4 installer crashes if launched on Red Hat 6.2 (RPM 3)
|
||||
system" - Explains what happens, and the context.</li>
|
||||
</ol>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
|
||||
[% INCLUDE global/footer.html.tmpl %]
|
||||
|
|
@ -0,0 +1,265 @@
|
|||
[%# 1.0@bugzilla.org %]
|
||||
[%# The contents of this file are subject to the Mozilla Public
|
||||
# License Version 1.1 (the "License"); you may not use this file
|
||||
# except in compliance with the License. You may obtain a copy of
|
||||
# the License at http://www.mozilla.org/MPL/
|
||||
#
|
||||
# Software distributed under the License is distributed on an "AS
|
||||
# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
|
||||
# implied. See the License for the specific language governing
|
||||
# rights and limitations under the License.
|
||||
#
|
||||
# The Original Code is the Bugzilla Bug Tracking System.
|
||||
#
|
||||
# The Initial Developer of the Original Code is Netscape Communications
|
||||
# Corporation. Portions created by Netscape are
|
||||
# Copyright (C) 1998 Netscape Communications Corporation. All
|
||||
# Rights Reserved.
|
||||
#
|
||||
# Contributor(s): Terry Weissman <terry@mozilla.org>
|
||||
# Gervase Markham <gerv@gerv.net>
|
||||
#%]
|
||||
|
||||
[% PROCESS global/variables.none.tmpl %]
|
||||
[% INCLUDE global/header.html.tmpl title = "A $terms.Bug's Life Cycle" %]
|
||||
|
||||
<p>
|
||||
The <b>status</b> and <b>resolution</b> fields define and track the life
|
||||
cycle of a [% terms.bug %].
|
||||
</p>
|
||||
|
||||
<a name="status"></a>
|
||||
<a name="resolution"></a>
|
||||
|
||||
<table border="1" cellpadding="4">
|
||||
<tr align="center" valign="top">
|
||||
<td width="50%">
|
||||
<h1>STATUS</h1>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<h1>RESOLUTION</h1>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td>The <b>status</b> field indicates the general health of a
|
||||
[% terms.bug %]. Only certain status transitions are allowed.</td>
|
||||
|
||||
<td>The <b>resolution</b> field indicates what happened to this
|
||||
[% terms.bug %].</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<dl>
|
||||
<dt><b>UNCONFIRMED</b></dt>
|
||||
|
||||
<dd>This [% terms.bug %] has recently been added to the database.
|
||||
Nobody has validated that this [% terms.bug %] is true. Users who have
|
||||
the "canconfirm" permission set may confirm this [% terms.bug %],
|
||||
changing its state to NEW. Or, it may be directly resolved and marked
|
||||
RESOLVED.</dd>
|
||||
|
||||
<dt><b>NEW</b></dt>
|
||||
|
||||
<dd>This [% terms.bug %] has recently been added to the assignee's list
|
||||
of [% terms.bugs %] and must be processed. [% terms.Bugs %] in this
|
||||
state may be accepted, and become <b>ASSIGNED</b>, passed on to someone
|
||||
else, and remain <b>NEW</b>, or resolved and marked <b>RESOLVED</b>.
|
||||
</dd>
|
||||
|
||||
<dt><b>ASSIGNED</b></dt>
|
||||
|
||||
<dd>This [% terms.bug %] is not yet resolved, but is assigned to the
|
||||
proper person. From here [% terms.bugs %] can be given to another
|
||||
person and become <b>NEW</b>, or resolved and become <b>RESOLVED</b>.
|
||||
</dd>
|
||||
|
||||
<dt><b>REOPENED</b></dt>
|
||||
|
||||
<dd>This [% terms.bug %] was once resolved, but the resolution was
|
||||
deemed incorrect. For example, a <b>WORKSFORME</b> [% terms.bug %] is
|
||||
<b>REOPENED</b> when more information shows up and the [% terms.bug %]
|
||||
is now reproducible. From here [% terms.bugs %] are either marked
|
||||
<b>ASSIGNED</b> or <b>RESOLVED</b>.</dd>
|
||||
</dl>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<dl>
|
||||
<dd>No resolution yet. All [% terms.bugs %] which are in one of
|
||||
these "open" states have the resolution set to blank. All
|
||||
other [% terms.bugs %] will be marked with one of the following
|
||||
resolutions.</dd>
|
||||
</dl>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<dl>
|
||||
<dt><b>RESOLVED</b></dt>
|
||||
|
||||
<dd>A resolution has been taken, and it is awaiting verification by
|
||||
QA. From here [% terms.bugs %] are either re-opened and become
|
||||
<b>REOPENED</b>, are marked <b>VERIFIED</b>, or are closed for good
|
||||
and marked <b>CLOSED</b>.</dd>
|
||||
|
||||
<dt><b>VERIFIED</b></dt>
|
||||
|
||||
<dd>QA has looked at the [% terms.bug %] and the resolution and
|
||||
agrees that the appropriate resolution has been taken. [% terms.Bugs %]
|
||||
remain in this state until the product they were reported against
|
||||
actually ships, at which point they become <b>CLOSED</b>.</dd>
|
||||
|
||||
<dt><b>CLOSED</b></dt>
|
||||
|
||||
<dd>The [% terms.bug %] is considered dead, the resolution is correct.
|
||||
Any zombie [% terms.bugs %] who choose to walk the earth again must
|
||||
do so by becoming <b>REOPENED</b>.</dd>
|
||||
</dl>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<dl>
|
||||
<dt><b>FIXED</b></dt>
|
||||
|
||||
<dd>A fix for this [% terms.bug %] is checked into the tree and
|
||||
tested.</dd>
|
||||
|
||||
<dt><b>INVALID</b></dt>
|
||||
|
||||
<dd>The problem described is not a [% terms.bug %]</dd>
|
||||
|
||||
<dt><b>WONTFIX</b></dt>
|
||||
|
||||
<dd>The problem described is a [% terms.bug %] which will never be
|
||||
fixed.</dd>
|
||||
|
||||
<dt><b>DUPLICATE</b></dt>
|
||||
|
||||
<dd>The problem is a duplicate of an existing [% terms.bug %]. Marking
|
||||
a [% terms.bug %] duplicate requires the [% terms.bug %]# of the
|
||||
duplicating [% terms.bug %] and will at least put that [% terms.bug %]
|
||||
number in the description field.</dd>
|
||||
|
||||
<dt><b>WORKSFORME</b></dt>
|
||||
|
||||
<dd>All attempts at reproducing this [% terms.bug %] were futile,
|
||||
reading the code produces no clues as to why this behavior would occur.
|
||||
If more information appears later, please re-assign
|
||||
the [% terms.bug %], for now, file it.</dd>
|
||||
|
||||
<dt><b>MOVED</b></dt>
|
||||
|
||||
<dd>The problem was specific to a related product
|
||||
whose [% terms.bugs %] are tracked in another [% terms.bug %] database.
|
||||
The [% terms.bug %] has been moved to that database.</dd>
|
||||
</dl>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h2><a name="bug_severity">Severity</a></h2>
|
||||
This field describes the impact of a [% terms.bug %].
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Blocker</th>
|
||||
|
||||
<td>Blocks development and/or testing work</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<th>Critical</th>
|
||||
|
||||
<td>crashes, loss of data, severe memory leak</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<th>Major</th>
|
||||
|
||||
<td>major loss of function</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<th>Minor</th>
|
||||
|
||||
<td>minor loss of function, or other problem where easy
|
||||
workaround is present</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<th>Trivial</th>
|
||||
|
||||
<td>cosmetic problem like misspelled words or misaligned
|
||||
text</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<th>Enhancement</th>
|
||||
|
||||
<td>Request for enhancement</td>
|
||||
</table>
|
||||
|
||||
<h2><a name="priority">Priority</a></h2>
|
||||
This field describes the importance and order in which a [% terms.bug %]
|
||||
should be fixed. This field is utilized by the
|
||||
programmers/engineers to prioritize their work to be done. The
|
||||
available priorities range from <b>P1</b> (most important) to
|
||||
<b>P5</b> (least important.)
|
||||
|
||||
|
||||
<h2><a name="rep_platform">Platform</a></h2>
|
||||
This is the hardware platform against which the [% terms.bug %] was
|
||||
reported. Legal platforms include:
|
||||
|
||||
<ul>
|
||||
<li>All (happens on all platforms; cross-platform [% terms.bug %])</li>
|
||||
|
||||
<li>Macintosh</li>
|
||||
|
||||
<li>PC</li>
|
||||
|
||||
<li>Sun</li>
|
||||
|
||||
<li>HP</li>
|
||||
</ul>
|
||||
<b>Note:</b> When searching, selecting the option "All" does not
|
||||
select [% terms.bugs %]
|
||||
assigned against any platform. It merely selects [% terms.bugs %] that are
|
||||
marked as occurring on all platforms, i.e. are designated "All".
|
||||
|
||||
<h2><a name="op_sys">Operating System</a></h2>
|
||||
This is the operating system against which the [% terms.bug %] was
|
||||
reported. Legal operating systems include:
|
||||
|
||||
<ul>
|
||||
<li>All (happens on all operating systems; cross-platform
|
||||
[% terms.bug %])</li>
|
||||
|
||||
<li>Windows 95</li>
|
||||
|
||||
<li>Mac System 8.0</li>
|
||||
|
||||
<li>Linux</li>
|
||||
</ul>
|
||||
Sometimes the operating system implies the platform, but not
|
||||
always. For example, Linux can run on PC and Macintosh and
|
||||
others.
|
||||
|
||||
<h2><a name="assigned_to">Assigned To</a></h2>
|
||||
|
||||
<p>
|
||||
This is the person in charge of resolving the [% terms.bug %]. Every time
|
||||
this field changes, the status changes to <b>NEW</b> to make it
|
||||
easy to see which new [% terms.bugs %] have appeared on a person's list.</p>
|
||||
|
||||
<p>
|
||||
The default status for queries is set to NEW, ASSIGNED and
|
||||
REOPENED. When searching for [% terms.bugs %] that have been resolved or
|
||||
verified, remember to set the status field appropriately.
|
||||
</p>
|
||||
|
||||
[% INCLUDE global/footer.html.tmpl %]
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
[%# 1.0@bugzilla.org %]
|
||||
[%# The contents of this file are subject to the Mozilla Public
|
||||
# License Version 1.1 (the "License"); you may not use this file
|
||||
# except in compliance with the License. You may obtain a copy of
|
||||
# the License at http://www.mozilla.org/MPL/
|
||||
#
|
||||
# Software distributed under the License is distributed on an "AS
|
||||
# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
|
||||
# implied. See the License for the specific language governing
|
||||
# rights and limitations under the License.
|
||||
#
|
||||
# The Original Code is the Bugzilla Bug Tracking System.
|
||||
#
|
||||
# The Initial Developer of the Original Code is Netscape Communications
|
||||
# Corporation. Portions created by Netscape are
|
||||
# Copyright (C) 1998 Netscape Communications Corporation. All
|
||||
# Rights Reserved.
|
||||
#
|
||||
# Contributor(s): Terry Weissman <terry@mozilla.org>
|
||||
# Gervase Markham <gerv@gerv.net>
|
||||
#%]
|
||||
|
||||
[% PROCESS global/variables.none.tmpl %]
|
||||
[% INCLUDE global/header.html.tmpl title = "Voting" %]
|
||||
|
||||
<p>[% terms.Bugzilla %] has a "voting" feature. Each product allows users to
|
||||
have a certain number of votes. (Some products may not allow any, which means
|
||||
you can't vote on things in that product at all.) With your vote, you indicate
|
||||
which [% terms.bugs %] you think are the most important to be fixed.</p>
|
||||
|
||||
<p>Depending on how the administrator has configured the relevant product,
|
||||
you may be able to vote for the same [% terms.bug %] more than one time. But
|
||||
remember, you only have so many votes to use in total! So, you can either vote
|
||||
a little for many [% terms.bugs %], or vote a lot for a few [% terms.bugs %].
|
||||
</p>
|
||||
|
||||
<p>To look at votes:</p>
|
||||
|
||||
<ul>
|
||||
<li>Go to the query page. Do a normal query, but enter 1 in the "At least
|
||||
___ votes" field. This will show you items that match your query that
|
||||
have at least one vote.</li>
|
||||
</ul>
|
||||
|
||||
<p>To vote for a [% terms.bug %]:</p>
|
||||
|
||||
<ul>
|
||||
<li>Bring up the [% terms.bug %] in question.</li>
|
||||
|
||||
<li>Click on the "Vote for this [% terms.bug %]" link that appears just
|
||||
above the "Additional Comments" field. (If no such link appears, then voting
|
||||
may not be allowed in this [% terms.bug %]'s product.)</li>
|
||||
|
||||
<li>Indicate how many votes you want to give this [% terms.bug %]. This page
|
||||
also displays how many votes you've given to other [% terms.bugs %], so you
|
||||
may rebalance your votes as necessary.</li>
|
||||
</ul>
|
||||
|
||||
<p>You will automatically get email notifying you of any changes that occur
|
||||
on [% terms.bugs %] you vote for.</p>
|
||||
|
||||
<p>You may review your votes at any time by clicking on the "<a href=
|
||||
"votes.cgi?action=show_user">My Votes</a>" link in the page footer.</p>
|
||||
|
||||
[% INCLUDE global/footer.html.tmpl %]
|
||||
Загрузка…
Ссылка в новой задаче