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 on SourceForge[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 feature request 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, except than 9 is
|
|
highest and 1 is lowest. One rule, however, is that bugs with
|
|
priority seven 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 CVS revision numbers of the
|
|
affected files. In the CVS checkin message, include the
|
|
SourceForge bug number *and* a normal description of the
|
|
change.
|
|
|
|
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://sourceforge.net/projects/python
|