mirror of https://github.com/python/cpython
61 lines
2.8 KiB
TeX
61 lines
2.8 KiB
TeX
\label{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
|
|
or its documentation.
|
|
|
|
Before submitting a report, you will be required to log into SourceForge;
|
|
this will make it possible for the developers to contact you
|
|
for additional information if needed. It is not possible to submit a
|
|
bug report anonymously.
|
|
|
|
All bug reports should be submitted via the Python Bug Tracker at
|
|
(\url{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 side of the page.
|
|
|
|
If the problem you're reporting is not already in the bug tracker, go
|
|
back to the Python Bug Tracker. Select the
|
|
``Create new'' link at the left of the page to open the bug reporting
|
|
form.
|
|
|
|
The submission form has a number of fields. The only fields that are
|
|
required are the ``Title'' and ``Type'' fields. For the title,
|
|
enter a \emph{very} short description of the problem; less than ten
|
|
words is good. In the ``Change Note'' field, describe the problem in detail,
|
|
including what you expected to happen and what did happen. Be sure to
|
|
include the version of Python you used, whether any extension modules
|
|
were involved, and what hardware and software platform you were using
|
|
(including version information as appropriate).
|
|
|
|
The only other field that you may want to set is the ``Components''
|
|
field, which allows you to place the bug report into broad categories
|
|
(such as ``Documentation'' or ``Library'').
|
|
|
|
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.
|
|
|
|
|
|
\begin{seealso}
|
|
\seetitle[http://www-mice.cs.ucl.ac.uk/multimedia/software/documentation/ReportingBugs.html]{How
|
|
to Report Bugs Effectively}{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.}
|
|
|
|
\seetitle[http://www.mozilla.org/quality/bug-writing-guidelines.html]{Bug
|
|
Writing Guidelines}{Information about writing a good bug
|
|
report. Some of this is specific to the Mozilla project, but
|
|
describes general good practices.}
|
|
\end{seealso}
|