Anonymous user
Triaging Python tickets: Difference between revisions
Undo revision 17690 by 117.239.152.85 (talk)
(Blanked the page) |
imported>Semenko (Undo revision 17690 by 117.239.152.85 (talk)) |
||
Line 1:
Welcome! This page contains instructions for triaging Python tickets, which is something anyone can do and is a great way to get started with contributing to Python.
This page focuses on 3 types of triage: verifying bugs, reviewing patches, and reviewing documentation patches.
[[File:Python_logo.png|200px]] [[File:Bug.png|200px]]
== Overview ==
[http://docs.python.org/devguide/triaging.html This section of the CPython developer guide] details triaging tickets. Please note that any registered user can comment on a ticket, but one must have "Developer" rights on the [http://bugs.python.org/ issue tracker] to update certain ticket fields.
If you don't have Developer rights, don't worry! Leave detailed comments on a ticket, and everyone on the [http://docs.python.org/devguide/triaging.html#nosy-list nosy list] will get an email. With your triage comments, you've greatly increased the chance that someone will move the ticket forward.
Also, if you do this for a while, you'll get Developer rights so you can make the ticket field changes yourself!
== Verifying bugs ==
[[File:Debugging.png|100px]]
Often, someone will report a bug, but nobody will want to work on a patch for it until the bug is confirmed. Thus, confirming a bug is a big step towards getting it fixed.
=== Bug verification checklist ===
If you '''can''' reproduce the bug:
# Say that you can reproduce the bug.
# Reiterate what you expected to happen, and what actually happened.
# Enumerate the steps you took to reproduce the problem. Do at least one of:
## include a complete transcript, including the commands you ran, Python code you entered at the interpreter, tracebacks, etc. If the output is very long, for readability, attach it to the ticket instead of putting it directly in the comment.
## Attach a short, standalone program that reproduces the bug to the ticket. This will be a helpful basis for writing test cases.
# List all versions of Python in which the bug was and wasn't present for you.
# List all operating systems on which the bug was and wasn't present for you.
If you '''can't''' reproduce the bug:
# Say that you can't reproduce the bug.
# Enumerate the steps you took to try and reproduce the problem.
# List all versions of Python in which the bug wasn't present for you.
# List all operating systems on which the bug wasn't present for you.
=== Example review ===
<blockquote>
jesstess, thanks for your bug report!<br />
<br />
I was able to reproduce the issue on both the default branch and in Python 3.4. I couldn't reproduce on 3.3, so this looks like a regression. I tested on OSX 10.8.4 but I believe this bug exists on all operating systems.<br />
<br />
I've attached a short script as a reproducer. The expected output is for it to print <code>42</code>, but it raises a <code>ValueError</code>.
</blockquote>
== Reviewing patches ==
[[File:Patch.png|100px]]
CPython committers are really busy, and they typically won't try to merge a patch until someone else has reviewed it. Thus, reviewing a patch is a big step towards getting it merged.
=== Patch review checklist ===
In your review, answer these questions:
# Does the patch apply cleanly?
# Does the patch make sense, and implement the solution in a straightforward way?
# If a bug fix, does the patch fix the problem it says it does? Two ways to assess this are:
## If the bug has a reproducer, verify that the reproducer doesn't fail with the patch applied.
## If the patch includes tests, verify that the tests fail with the code changes reverted.
# Does [http://docs.python.org/devguide/patch.html#generation make patchcheck] pass?
# Is the patch accompanied by [http://docs.python.org/devguide/runtests.html new tests] that either exercise the bug or the new functionality?
# Do the tests impacted by the patch still pass? (The committer will run the whole test suite, but you can [http://docs.python.org/devguide/runtests.html#runtests run just the relevant tests])
# If functionality was added or changed, is the patch accompanied by new or updated [http://docs.python.org/devguide/documenting.html documentation]?
=== Example patch review ===
<blockquote>
jesstess, thanks for your patch and tests!<br />
<br />
The docstring for <code>parse_request</code> needs to be updated as part of this change.<br />
<br />
Other than that, the patch looks correct from my inspection, applies cleanly, and implements a straightforward solution.<br />
<br />
I verified that with the patch applied, the reproducer no longer raises a <code>ValueError</code> and instead prints <code>42</code> as expected. <code>make patchcheck</code> also reports no errors, and the <code>test_httplib</code> tests still pass. I confirmed that the tests for parsing unicode strings that were added in this patch exercise the bug, as they fail with the code changes reverted and pass with the full patch applied.<br />
<br />
After the docstring is updated, I think this is ready for a commit review!
</blockquote>
== Reviewing documentation patches ==
[[File:History.png|100px]]
Documentation patches have some different steps from code patches. They don't generally require accompanying tests, and they should be inspected visually for correctness.
=== Documentation patch review checklist ===
In your review, answer these questions:
# Does the patch apply cleanly?
# Is the documentation change correct, succinct, spelling error free, and grammatically correct?
# Does [http://docs.python.org/devguide/patch.html#generation make patchcheck] pass?
# Does the documentation [http://docs.python.org/devguide/documenting.html#building-the-documentation build without errors]? In general, building just the HTML docs is sufficient.
# Does the resulting HTML look reasonable? (For example: is the code formatted correctly, do the footnote links work)
=== Example documentation review ===
<blockquote>
jesstess, thanks for your patch!<br />
<br />
The docs build cleanly with the patch. I visually inspected the changes in the built HTML docs and they look good. I also ran the modified example code from the docs and confirmed that it runs as expected.
I think this is ready for a commit review!
</blockquote>
== Finding tickets to triage ==
Bug reports that need verifying are typically in the [http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=3&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search "needs patch" stage].
Patches that need review are typically in the [http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=4&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search "patch review" stage].
Documentation tickets are typically in the [http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=4&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=4&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search "Documentation" component].
| |||