-
Notifications
You must be signed in to change notification settings - Fork 39
/
handling-bugs.php
226 lines (184 loc) · 8.16 KB
/
handling-bugs.php
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
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
<?php
include("include/functions.php");
$TITLE = "Handling Bug Reports [PHP-QAT: Quality Assurance Team]";
$SITE_UPDATE = date("D M d H:i:s Y T", filectime(__FILE__));
$CURRENT_PAGE = "Handling Reports";
common_header();
?>
<h1>Handling bug reports?</h1>
<h2>Introduction</h2>
<p>
Welcome to the HOWTO on managing PHP bugs via <a
href="https://bugs.php.net/">bugs.php.net</a>. PHP is a large project with many
bugs being submitted daily. Bug topics range from the PHP website itself,
various PHP extensions, PEAR, etc. This document is for all PHP developers
using the bug system. Because there are so many members using the system it's
important we act in a consistent manner. This HOWTO is created to solve this.
</p>
<p>If you're going to edit a bug be sure that you know the topic. Don't make
assumptions. If you've read the bug carefully and think of a solution or
related questions, post your answer/comments. If you know of the solution,
solve and close the bug.</p>
<h2>Acting on a bug</h2>
<p>Never change a status if you're not sure. If you close a bug because you
think it's not really a bug and in fact it is, this makes the bug system
useless and doesn't benefit anyone. Never close a bug because it's too old,
unless your name is Jani. If a bug is in "feedback" status it will close
automatically if the bug reporter doesn't answer after two weeks.</p>
<p>If you want to view a bug report, enter the bug id into the url like
so (with 20406 being an example):</p>
<ul>
<li>
<a href="https://bugs.php.net/20406">https://bugs.php.net/20406</a>
</li>
</ul>
<p>Which redirects to:</p>
<ul>
<li>
<a href="https://bugs.php.net/bug.php?id=20406">https://bugs.php.net/bug.php?id=20406</a>
</li>
</ul>
<p>At that point you'll see a set of options. Because you're a developer you
will choose the developer option which will then put you here:</p>
<ul>
<li>
<a href="https://bugs.php.net/bug.php?id=20406&edit=1">https://bugs.php.net/bug.php?id=20406&edit=1</a>
</li>
</ul>
<h2>Automatic answers (quickfix)</h2>
<p>There are a set of quickfix options each of which will both insert text into
the bug report and change the bug status. Please understand what text and
status will be used and only choose a quickfix option if an appropriate
quickfix exists. Choosing a quickfix that's not 100% correct will confuse
and sometimes irritate the reporter. The following table lists them (see
also <a href="https://bugs.php.net/quick-fix-desc.php">quick-fix-desc.php</a>):</p>
<h2>Manual answers</h2>
<p>If no quickfix is available you will manually choose the new status and
write some feedback. Select the best status that corresponds to the bug.
Here are descriptions for each status:</p>
<p>
<dl>
<dt>Open</dt>
<dd>
The bug still exists and you want to comment on it.
</dd>
<dt>Closed</dt>
<dd>
It has been fixed. If you choose this please make sure
it's also been documented. Also, explain why it's closed.
</dd>
<dt>Duplicate</dt>
<dd>
This status is deprecated and can no longer be selected during
modifications of bugs. Always use "Not a Bug" instead now. The originial
use was:
<i>If this almost the same bug, both bugs are found 'duplicate' later
on and have both useful information. Also mention what bug it's a
duplicate of with a full url to the report this is duplicate of.</i>
</dd>
<dt>Critical</dt>
<dd>
Only bugs that affect most/all users and/or are in the engine or
ext/standard. Only Verified and reproduced bugs in the latest
Git revision can be marked critical.
</dd>
<dt>Assigned</dt>
<dd>
If a specific person, such as yourself, will take of this bug then
assign it. If you know someone else is or will take care of it then assign
it to them but be sure to ask them first.
</dd>
<dt>Analyzed</dt>
<dd>
If you've analyzed why this bug is here and know why the bug exists, you
have just analyzed it. Also, add a comment. If you are unsure why it
exists then use 'verified' instead.
</dd>
<dt>Verified</dt>
<dd>
If you're able to reproduce this bug with the information given.
Be sure to test with the latest Git. Typically you aren't sure why
it exists you just know it does and have confirmed it.
</dd>
<dt>Suspended</dt>
<dd>
Usually used when there might be a fix in future and/or it relies on
something external to be fixed first.
</dd>
<dt>Wont fix</dt>
<dd>When something is not considered a bug or the bug is not fixable.</dd>
<dt>No feedback</dt>
<dd>
If no answer have been given by the reporter after we've asked them
something. Sometimes you will ask for an example script or ask the
reporter to test using Git.
</dd>
<dt>Feedback</dt>
<dd>
You're asking the reporter for more information such as please use
Git revision, and/or the smallest possible test script to reproduce the
error, and/or a value for a certain PHP directive.
</dd>
<dt>Not a Bug (old: Bogus)</dt>
<dd>
This bug is not a bug, support related or just an assumed bug or the
bug already exists in the database. Be 100% it's really "bogus" and
also be sure it's not a documentation bug.
</dd>
</dl>
<h2>Reclassification</h2>
<p>Sometimes you'll also want to reclassify a bug. For example, a reporter
marks a bug as Apache2 related when really it's a MySQL bug. Just change
the category but be 100% sure it's related to the new category. Another
example would be changing the type to a documentation bug. If you're
changing it to a documentation bug it will help the documentation team if you
add specific information that is to be documented including what version the
changes will take place.</p>
<p>Also note that all bugs are sent to various mailing lists with
[email protected] being the default (most go here). Here's a list:</p>
<dl>
<dt>Default</dt>
<dd><a href="http://news.php.net/php.bugs">[email protected]</a></dd>
<dt>Documentation</dt>
<dd><a href="http://news.php.net/php.doc">[email protected]</a></dd>
<dt>PEAR</dt>
<dd><a href="http://news.php.net/php.pear.dev">[email protected]</a></dd>
<dt>PHP.net Website</dt>
<dd><a href="http://news.php.net/php.mirrors">[email protected]</a></dd>
</dl>
<p>Reclassifying will immediatly change which mailing list is used. If you
reclassify a bug and don't leave a comment then no email is sent to the mailing list.
So, be sure to leave a comment.</p>
<h2>Tips and links</h2>
<ul>
<li>
The Jani Javascript bug popup window (right click to bookmark):
<a href='javascript:void(t=prompt("Get BUG report # ..",""));if(t){ void(top.location.href="https://bugs.php.net/bug.php?edit=1&id="+t);}'>here</a>
</li>
<li>
Look at the <a href="https://bugs.php.net/stats.php">raw bug stats</a>.
</li>
<li>
Not leaving a comment means no email will be sent to the mailing list.
(all quickfix options leave comments)
</li>
<li>
If a version is from Git be sure to label it in the form:
<b>x.y.z-dev</b> An example is: 5.6.0-dev or 7.0.0-dev.
</li>
<li>
If you have a question either email the
<a href="mailto:[email protected]">[email protected]</a>
mailing list or check out the #php.pecl channel in IRC on
<a href="http://www.irchelp.org/networks/efnet/">EFNET</a>.
</li>
</ul>
<h2>Conclusion</h2>
<p>If everyone maintains the bug system in a consistent manner then PHP will
be better for it. Also, bug reporters will not get their feelings hurt
through miscommunication (e.g. a wrong quickfix or bogus status) Thank you
for reading this HOWTO and helping make PHP better.</p>
<br />
<?php
common_footer();
?>