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)) |
||
| (15 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]]
Line 7:
== 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 48 ⟶ 50:
== 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 60 ⟶ 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 69 ⟶ 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 79 ⟶ 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 98 ⟶ 104:
<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>
| |||