Triaging Python tickets: Difference between revisions

Content added Content deleted

Inline

Revision as of 18:27, 18 March 2014

Python has a ton of stalled tickets, and in particular tickets that report bugs that haven't been confirmed, or that have patches that haven't been reviewed. Python needs more people triaging these tickets; want to help?

Overview

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 in the issue tracker to update fields.

If you don't have Developer rights, don't worry! Leave detailed comments on a ticket, and everyone on the nosy list will get an email. With your documented triage, you've greatly increased the chance that someone who can update the fields will review your comments and 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

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.

Triage comment 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. 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.
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.
Attach a short, standalone program that reproduces the bug to the ticket. This will be a helpful basis for writing test cases.

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.

Reviewing patches

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.

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:
1. If the bug has a reproducer, verify that the reproducer doesn't fail with the patch applied.
2. If the patch includes tests, verify that the tests fail with the code changes reverted.
Does make patchcheck pass?
Do the tests impacted by the patch still pass? (The committer will run the whole test suite, but you can run just the relevant tests)

In most cases, code changes must be accompanied by tests before they will get merged.

@@ Line 13: / Line 13: @@
 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.
+=== Triage comment checklist ===
-If you can reproduce a bug, here's an ideal triage comment:
+If you '''can''' reproduce the bug:
 # Say that you can reproduce the bug.
@@ Line 21: / Line 23: @@
 # List all operating systems on which the bug was and wasn't present for you.
 # Attach a short, standalone program that reproduces the bug to the ticket. This will be a helpful basis for writing test cases.
+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.
 == Reviewing patches ==
+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.
+=== 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?
+# 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])
+In most cases, code changes must be accompanied by tests before they will get merged.
 == Reviewing documentation ==