65 lines
2.3 KiB
Plaintext
65 lines
2.3 KiB
Plaintext
PEP: 3
|
|
Title: Guidelines for Handling Bug Reports
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: jeremy@alum.mit.edu (Jeremy Hylton)
|
|
Status: Active
|
|
Type: Process
|
|
Created: 25-Sep-2000
|
|
Post-History:
|
|
|
|
Introduction
|
|
|
|
This PEP contains guidelines for handling bug reports to the
|
|
Python project at the tracker [1]. Still to be done is to collect
|
|
a list of people willing to handle bug reports and their areas of
|
|
expertise.
|
|
|
|
These are guidelines for the developers of Python, not the
|
|
submitters of bugs. Those are at
|
|
|
|
http://docs.python.org/lib/reporting-bugs.html
|
|
|
|
(though this hardly seems the best place).
|
|
|
|
|
|
Guidelines
|
|
|
|
1. Make sure the bug category and bug group are correct. If they
|
|
are correct, it is easier for someone interested in helping to
|
|
find out, say, what all the open Tkinter bugs are.
|
|
|
|
2. If it's a minor feature request that you don't plan to address
|
|
right away, add it to PEP 42 or ask the owner to add it for
|
|
you. If you add the bug to PEP 42, mark the bug as "feature
|
|
request", "later", and "closed"; and add a comment to the bug
|
|
saying that this is the case (mentioning the PEP explicitly).
|
|
|
|
XXX do we prefer the tracker or PEP 42?
|
|
|
|
3. Assign the bug a reasonable priority. We don't yet have a
|
|
clear sense of what each priority should mean. One rule,
|
|
however, is that bugs with priority "urgent" or higher must
|
|
be fixed before the next release.
|
|
|
|
4. If a bug report doesn't have enough information to allow you to
|
|
reproduce or diagnose it, ask the original submitter for more
|
|
information. If the original report is really thin and your
|
|
email doesn't get a response after a reasonable waiting period,
|
|
you can close the bug.
|
|
|
|
5. If you fix a bug, mark the status as "Fixed" and close it. In
|
|
the comments, include the SVN revision numbers of the commit(s).
|
|
In the SVN checkin message, include the issue number *and* a
|
|
normal description of the change, mentioning the contributor
|
|
if a patch was applied.
|
|
|
|
6. If you are assigned a bug that you are unable to deal with,
|
|
assign it to someone else if you think they will be able to
|
|
deal with it, otherwise it's probably best to unassign it.
|
|
|
|
|
|
References
|
|
|
|
[1] http://bugs.python.org/
|