Anonymous user
Triaging Python tickets: Difference between revisions
Undo revision 17690 by 117.239.152.85 (talk)
imported>Jesstess No edit summary |
imported>Semenko (Undo revision 17690 by 117.239.152.85 (talk)) |
||
| (18 intermediate revisions by 2 users not shown) | |||
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
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
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.
Line 41 ⟶ 47:
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 won't typically try to merge a patch until someone else has reviewed it. Thus, reviewing a patch is a big step towards getting it merged.▼
▲CPython committers are really busy, and they typically won't
=== Patch review checklist ===
Line 57 ⟶ 64:
## 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 ===
Line 66 ⟶ 73:
jesstess, thanks for your patch and tests!<br />
<br />
The docstring for <code>parse_request</code> needs to be updated as part of this
<br />
Other than that, the patch looks correct from my inspection, applies cleanly, and implements a straightforward solution.<br />
Line 76 ⟶ 83:
== 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.
Line 88 ⟶ 97:
# 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].
| |||