iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Restify PEP-3

This commit is contained in:
Matthias Bussonnier 2016-06-19 12:32:58 -07:00
parent cce5754f28
commit bf195b69e3
1 changed files with 44 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
pep-0003.txt
View File

@ -5,57 +5,68 @@ Last-Modified: $Date$
Author: jeremy@alum.mit.edu (Jeremy Hylton) Author: jeremy@alum.mit.edu (Jeremy Hylton)
Status: Withdrawn Status: Withdrawn
Type: Process Type: Process
Content-Type: text/x-rst
Created: 25-Sep-2000 Created: 25-Sep-2000
Post-History: Post-History:
Introduction Introduction
============
This PEP contained guidelines for handling bug reports in This PEP contained guidelines for handling bug reports in the Python
the Python bug tracker. It has been replaced by the Developer's bug tracker. It has been replaced by the Developer's Guide
Guide description of issue triaging at description of issue triaging at
https://docs.python.org/devguide/triaging.html ::
Guidelines for people submitting Python bugs are at https://docs.python.org/devguide/triaging.html
http://docs.python.org/bugs.html Guidelines for people submitting Python bugs are at
::
http://docs.python.org/bugs.html
Original Guidelines Original Guidelines
===================
1. Make sure the bug category and bug group are correct. If they 1. Make sure the bug category and bug group are correct. If they are
are correct, it is easier for someone interested in helping to correct, it is easier for someone interested in helping to find
find out, say, what all the open Tkinter bugs are. out, say, what all the open Tkinter bugs are.
2. If it's a minor feature request that you don't plan to address 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 right away, add it to PEP 42 or ask the owner to add it for you.
you. If you add the bug to PEP 42, mark the bug as "feature If you add the bug to PEP 42, mark the bug as "feature request",
request", "later", and "closed"; and add a comment to the bug "later", and "closed"; and add a comment to the bug saying that
saying that this is the case (mentioning the PEP explicitly). 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 XXX do we prefer the tracker or PEP 42?
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 3. Assign the bug a reasonable priority. We don't yet have a clear
reproduce or diagnose it, ask the original submitter for more sense of what each priority should mean. One rule, however, is
information. If the original report is really thin and your that bugs with priority "urgent" or higher must be fixed before
email doesn't get a response after a reasonable waiting period, the next release.
you can close the bug.
5. If you fix a bug, mark the status as "Fixed" and close it. In 4. If a bug report doesn't have enough information to allow you to
the comments, include the SVN revision numbers of the commit(s). reproduce or diagnose it, ask the original submitter for more
In the SVN checkin message, include the issue number *and* a information. If the original report is really thin and your email
normal description of the change, mentioning the contributor doesn't get a response after a reasonable waiting period, you can
if a patch was applied. close the bug.
6. If you are assigned a bug that you are unable to deal with, 5. If you fix a bug, mark the status as "Fixed" and close it. In the
assign it to someone else if you think they will be able to comments, include the SVN revision numbers of the commit(s). In
deal with it, otherwise it's probably best to unassign it. 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 References
==========
[1] http://bugs.python.org/ .. [1] http://bugs.python.org/