cpython/Doc/bugs.rst
Benjamin Peterson a786b026c9 Merged revisions 65910,65977,65980,65984,65986,66000,66011-66012,66014,66017,66020 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk

........
  r65910 | benjamin.peterson | 2008-08-20 09:07:59 -0500 (Wed, 20 Aug 2008) | 1 line

  fix up the multiprocessing docs a little
........
  r65977 | christian.heimes | 2008-08-22 14:47:25 -0500 (Fri, 22 Aug 2008) | 3 lines

  Silenced compiler warning
  Objects/stringlib/find.h:97: warning: 'stringlib_contains_obj' defined but not used
  Reviewed by Benjamin Peterson
........
  r65980 | christian.heimes | 2008-08-22 15:10:27 -0500 (Fri, 22 Aug 2008) | 3 lines

  Fixed two format strings in the _collections module. For example
  Modules/_collectionsmodule.c:674: warning: format '%i' expects type 'int', but argument 2 has type 'Py_ssize_t'
  Reviewed by Benjamin Peterson
........
  r65984 | christian.heimes | 2008-08-22 16:23:47 -0500 (Fri, 22 Aug 2008) | 1 line

  d is the correct format string
........
  r65986 | mark.hammond | 2008-08-22 19:59:14 -0500 (Fri, 22 Aug 2008) | 2 lines

  Fix bug 3625: test issues on 64bit windows. r=pitrou
........
  r66000 | benjamin.peterson | 2008-08-23 15:27:43 -0500 (Sat, 23 Aug 2008) | 5 lines

  #3643 add a few more checks to _testcapi to prevent segfaults

  Author: Victor Stinner
  Reviewer: Benjamin Peterson
........
  r66011 | neal.norwitz | 2008-08-24 12:27:43 -0500 (Sun, 24 Aug 2008) | 1 line

  Ignore a couple more tests that report leaks inconsistently.
........
  r66012 | neal.norwitz | 2008-08-24 12:29:53 -0500 (Sun, 24 Aug 2008) | 1 line

  Use the actual blacklist of leaky tests
........
  r66014 | georg.brandl | 2008-08-24 13:11:07 -0500 (Sun, 24 Aug 2008) | 2 lines

  #3654: fix duplicate test method name. Review by Benjamin P.
........
  r66017 | benjamin.peterson | 2008-08-24 16:55:03 -0500 (Sun, 24 Aug 2008) | 1 line

  remove note about unimplemented feature
........
  r66020 | brett.cannon | 2008-08-24 18:15:19 -0500 (Sun, 24 Aug 2008) | 1 line

  Clarify that some attributes/methods are listed somewhat separately because they are not part of the threading API.
........
2008-08-25 21:05:21 +00:00

56 lines
2.6 KiB
ReStructuredText

.. _reporting-bugs:
************************
Reporting Bugs in Python
************************
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.
Bug reports 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. If you don't already have a tracker account, select the
"Register" link in the sidebar and undergo the registration procedure.
Otherwise, if you're not logged in, enter your credentials and select "Login".
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.
.. 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.