mirror of
https://github.com/python/cpython.git
synced 2024-11-24 17:47:13 +01:00
d6abb72a79
svn+ssh://svn.python.org/python/branches/py3k
................
r77236 | georg.brandl | 2010-01-02 15:51:12 +0100 (Sa, 02 Jan 2010) | 1 line
#7592: remove duplicate description.
................
r77383 | georg.brandl | 2010-01-09 10:48:46 +0100 (Sa, 09 Jan 2010) | 9 lines
Merged revisions 77382 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77382 | georg.brandl | 2010-01-09 10:47:11 +0100 (Sa, 09 Jan 2010) | 1 line
#7422: make it clear that getargspec() only works on Python functions.
........
................
r77399 | georg.brandl | 2010-01-09 23:39:42 +0100 (Sa, 09 Jan 2010) | 1 line
Remove redundant brackets in signatures.
................
r77857 | georg.brandl | 2010-01-30 18:54:04 +0100 (Sa, 30 Jan 2010) | 1 line
#7814: fix wrong example function usage.
................
r78238 | georg.brandl | 2010-02-19 10:10:15 +0100 (Fr, 19 Feb 2010) | 1 line
#5341: fix parenthesis placement.
................
r78861 | georg.brandl | 2010-03-12 11:04:37 +0100 (Fr, 12 Mär 2010) | 1 line
Make tool compatible with 2.x and 3.x.
................
r78862 | georg.brandl | 2010-03-12 11:06:40 +0100 (Fr, 12 Mär 2010) | 13 lines
Merged revisions 78859-78860 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78859 | georg.brandl | 2010-03-12 10:57:43 +0100 (Fr, 12 Mär 2010) | 1 line
Get rid of backticks.
........
r78860 | georg.brandl | 2010-03-12 11:02:03 +0100 (Fr, 12 Mär 2010) | 1 line
Fix warnings from "make check".
........
................
r78958 | georg.brandl | 2010-03-14 11:51:01 +0100 (So, 14 Mär 2010) | 37 lines
Merged revisions 78101,78115,78117,78182,78188,78245,78386,78496 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78101 | georg.brandl | 2010-02-08 01:04:54 +0100 (Mo, 08 Feb 2010) | 1 line
Fix test_fnmatch.
........
r78115 | georg.brandl | 2010-02-08 23:40:51 +0100 (Mo, 08 Feb 2010) | 1 line
Fix missing string formatting placeholder.
........
r78117 | georg.brandl | 2010-02-08 23:48:37 +0100 (Mo, 08 Feb 2010) | 1 line
Convert test failure from output-producing to self.fail().
........
r78182 | georg.brandl | 2010-02-14 09:18:23 +0100 (So, 14 Feb 2010) | 1 line
#7926: fix stray parens.
........
r78188 | georg.brandl | 2010-02-14 14:38:12 +0100 (So, 14 Feb 2010) | 1 line
#7926: fix-up wording.
........
r78245 | georg.brandl | 2010-02-19 20:36:08 +0100 (Fr, 19 Feb 2010) | 1 line
#7967: PyXML is no more.
........
r78386 | georg.brandl | 2010-02-23 22:48:57 +0100 (Di, 23 Feb 2010) | 1 line
#6544: fix refleak in kqueue, occurring in certain error conditions.
........
r78496 | georg.brandl | 2010-02-27 15:58:08 +0100 (Sa, 27 Feb 2010) | 1 line
Link to http://www.python.org/dev/workflow/ from bugs page.
........
................
74 lines
3.2 KiB
ReStructuredText
74 lines
3.2 KiB
ReStructuredText
.. _reporting-bugs:
|
|
|
|
**************
|
|
Reporting Bugs
|
|
**************
|
|
|
|
Python is a mature programming language which has established a reputation for
|
|
stability. In order to maintain this reputation, the developers would like to
|
|
know of any deficiencies you find in Python.
|
|
|
|
|
|
Documentation bugs
|
|
==================
|
|
|
|
If you find a bug in this documentation or would like to propose an improvement,
|
|
please send an e-mail to docs@python.org describing the bug and where you found
|
|
it. If you have a suggestion how to fix it, include that as well.
|
|
|
|
docs@python.org is a mailing list run by volunteers; your request will be
|
|
noticed, even if it takes a while to be processed.
|
|
|
|
Of course, if you want a more persistent record of your issue, you can use the
|
|
issue tracker for documentation bugs as well.
|
|
|
|
|
|
Using the Python issue tracker
|
|
==============================
|
|
|
|
Bug reports for Python itself should be submitted via the Python Bug Tracker
|
|
(http://bugs.python.org/). The bug tracker offers a Web form which allows
|
|
pertinent information to be entered and submitted to the developers.
|
|
|
|
The first step in filing a report is to determine whether the problem has
|
|
already been reported. The advantage in doing so, aside from saving the
|
|
developers time, is that you learn what has been done to fix it; it may be that
|
|
the problem has already been fixed for the next release, or additional
|
|
information is needed (in which case you are welcome to provide it if you can!).
|
|
To do this, search the bug database using the search box on the top of the page.
|
|
|
|
If the problem you're reporting is not already in the bug tracker, go back to
|
|
the Python Bug Tracker and log in. If you don't already have a tracker account,
|
|
select the "Register" link or, if you use OpenID, one of the OpenID provider
|
|
logos in the sidebar. It is not possible to submit a bug report anonymously.
|
|
|
|
Being now logged in, you can submit a bug. Select the "Create New" link in the
|
|
sidebar to open the bug reporting form.
|
|
|
|
The submission form has a number of fields. For the "Title" field, enter a
|
|
*very* short description of the problem; less than ten words is good. In the
|
|
"Type" field, select the type of your problem; also select the "Component" and
|
|
"Versions" to which the bug relates.
|
|
|
|
In the "Comment" field, describe the problem in detail, including what you
|
|
expected to happen and what did happen. Be sure to include whether any
|
|
extension modules were involved, and what hardware and software platform you
|
|
were using (including version information as appropriate).
|
|
|
|
Each bug report will be assigned to a developer who will determine what needs to
|
|
be done to correct the problem. You will receive an update each time action is
|
|
taken on the bug. See http://www.python.org/dev/workflow/ for a detailed
|
|
description of the issue workflow.
|
|
|
|
|
|
.. seealso::
|
|
|
|
`How to Report Bugs Effectively <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_
|
|
Article which goes into some detail about how to create a useful bug report.
|
|
This describes what kind of information is useful and why it is useful.
|
|
|
|
`Bug Writing Guidelines <http://developer.mozilla.org/en/docs/Bug_writing_guidelines>`_
|
|
Information about writing a good bug report. Some of this is specific to the
|
|
Mozilla project, but describes general good practices.
|
|
|