Hello,
I would like to advocate again for the removal of the "unit test needed" stage on the tracker, which regularly confuses our triagers into thinking it's an actual requirement or expectation from contributors and bug reporters.
Regards
Antoine.
I would like to advocate again for the removal of the "unit test needed" stage on the tracker, which regularly confuses our triagers into thinking it's an actual requirement or expectation from contributors and bug reporters.
Speaking as a bug triager: +1 to rename it “test needed” +1 to remove it
Regards
Am 10.01.2011 19:21, schrieb Éric Araujo:
I would like to advocate again for the removal of the "unit test needed" stage on the tracker, which regularly confuses our triagers into thinking it's an actual requirement or expectation from contributors and bug reporters.
Speaking as a bug triager: +1 to rename it “test needed” +1 to remove it
First rename, then remove?
Georg
On Mon, Jan 10, 2011 at 1:49 PM, Éric Araujo merwok@netwok.org wrote:
+1 to rename it “test needed” +1 to remove it
I meant either one would be an improvement.
+1 to remove it
Let's remove it first, an then decide if another stage is necessary. The problems with "unit test needed" is that
1. It is not clear whether unit tests should be written before or after a patch and thus once a bug is acknowledged as valid, what an appropriate stage should be.
2. For a bug that needs confirmation as being reproducible, it suggests that familiarity with unit test framework in necessary to move the issue forward. In fact, in many cases a short stand-alone script is more helpful than a Lib/test patch.
I think "patch needed" is a good enough first stage. For bugs it should be set when there is a rough consensus that the behavior is a bug and for RFEs, it should be set when a decision to include cannot be made without an implementation.
While there is no agreement on whether the bug is valid or whether an RFE makes any sense, the stage can stay undefined.
On 10/01/2011 19:48, Alexander Belopolsky wrote:
On Mon, Jan 10, 2011 at 1:49 PM, Éric Araujomerwok@netwok.org wrote:
+1 to rename it “test needed” +1 to remove it
I meant either one would be an improvement.
+1 to remove it
Let's remove it first, an then decide if another stage is necessary. The problems with "unit test needed" is that
- It is not clear whether unit tests should be written before or
after a patch and thus once a bug is acknowledged as valid, what an appropriate stage should be.
- For a bug that needs confirmation as being reproducible, it
suggests that familiarity with unit test framework in necessary to move the issue forward. In fact, in many cases a short stand-alone script is more helpful than a Lib/test patch.
I think "patch needed" is a good enough first stage. For bugs it should be set when there is a rough consensus that the behavior is a bug and for RFEs, it should be set when a decision to include cannot be made without an implementation.
Agree. "Patch needed" applies if the patch is incomplete, and if it lacks tests then it is incomplete.
Michael
While there is no agreement on whether the bug is valid or whether an RFE makes any sense, the stage can stay undefined. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
I would like to advocate again for the removal of the "unit test needed" stage on the tracker, which regularly confuses our triagers into thinking it's an actual requirement or expectation from contributors and bug reporters.
Perhaps a different wording would be preferred to removal. Suppose a reviewer accepts a patch but asks for a test before committing it. If it's hidden in the issue discussion, only those involved in the issue are aware of the situation. If it's in the issue state, then other potential contributors may notice it and provide tests. IMHO tests are simpler and less "scary" for newbies making their first steps in CPython.
Eli
Le 10/01/2011 20:11, Eli Bendersky a écrit :
Perhaps a different wording would be preferred to removal. Suppose a reviewer accepts a patch but asks for a test before committing it.
Well, we usually forewarn that a patch should include tests and docs, so I think “patch needed” or “patch review” is good enough.
Regards
On Mon, 10 Jan 2011 21:11:23 +0200 Eli Bendersky eliben@gmail.com wrote:
I would like to advocate again for the removal of the "unit test needed" stage on the tracker, which regularly confuses our triagers into thinking it's an actual requirement or expectation from contributors and bug reporters.
Perhaps a different wording would be preferred to removal. Suppose a reviewer accepts a patch but asks for a test before committing it. If it's hidden in the issue discussion, only those involved in the issue are aware of the situation. If it's in the issue state, then other potential contributors may notice it and provide tests. IMHO tests are simpler and less "scary" for newbies making their first steps in CPython.
Then we would need a whole array of checkboxes for things missing in a patch: - missing unit test - missing documentation changes - other things?
I don't think it's useful. As for "tests are simpler", it really depends on the issue :) I've worked on many issues where writing the test took much more time than actually fixing the bug (one-line fix vs. careful test setup to exercise the fix).
(also, as a matter of principle, I think it's better that the same person who wrote the bugfix is asked to write the tests)
Regards
Antoine.
Antoine> Then we would need a whole array of checkboxes for things Antoine> missing in a patch: Antoine> - missing unit test Antoine> - missing documentation changes Antoine> - other things?
How about replacing all the possibilities with
patch incomplete
then elaborate in the issue itself how that is the case.
Antoine> I don't think it's useful. As for "tests are simpler", it Antoine> really depends on the issue :) I've worked on many issues where Antoine> writing the test took much more time than actually fixing the Antoine> bug (one-line fix vs. careful test setup to exercise the fix).
I would rather write event-driven code than the test cases for it. ;-)
Skip
On Tue, Jan 11, 2011 at 6:37 AM, skip@pobox.com wrote:
How about replacing all the possibilities with
patch incomplete
then elaborate in the issue itself how that is the case.
+1
This is much clearer than lumping incomplete patches in with nonexistent ones. A process that goes "needs patch->patch review->(patch incomplete)->commit review->committed/rejected" (with the possibility of multiple iterations between patch review and patch incomplete) would give a pretty clear idea of where any given issue stands.
The "unit test needed" stage is actually more a "confirmation needed" stage - i.e. can the reported bug actually be reproduced by anyone other than the original reporter.
Cheers, Nick.
On Mon, Jan 10, 2011 at 22:37, skip@pobox.com wrote:
Antoine> Then we would need a whole array of checkboxes for things Antoine> missing in a patch: Antoine> - missing unit test Antoine> - missing documentation changes Antoine> - other things?
How about replacing all the possibilities with
patch incomplete
then elaborate in the issue itself how that is the case.
+1
On 01/10/2011 12:01 PM, Antoine Pitrou wrote:
Hello,
I would like to advocate again for the removal of the "unit test needed" stage on the tracker, which regularly confuses our triagers into thinking it's an actual requirement or expectation from contributors and bug reporters.
This keeps coming up because the logic of the different things in the tracker are not as clearly defined as they could be.
There are differences between a sequential stage, and a non-sequential requirement or status. Here's an example of separating those well.
Status: (Set as required) __ Bug - Set in New stage. __ Feature-request - Set in New stage. __ Commit-approved - Set in Patch-ready stage. __ Closed-committed - set in final stage. __ Closed-rejected - Set in any stage. (Add message for reason.)
Stage: (Set next stage as each stage is completed) __ New - Check Validity, set Bug or Feature request status, and set Requirements as needed. __ Patch-development - Until requirements are satisfied. __ Patch-ready - Set Commit-approved if/when accepted. __ Final - Set Closed-committed status after commit.
Requirements: (Set all that is needed, preferable in New stage.) __ Code patch __ Test patch __ Docs patch __ PEP Needed.
User input: __ request-review - Set by tracker user. (Add message for reason.)
Notes:
+ Patch-ready is be a nicer description of the Commit-review stage. + Remove "unittest needed" from stage, as its a requirement, not a stage. + Languishing should be a keyword. + Pending is too vague! (please remove!) + Move feature-request from type to status. + Add bug to status.
"Bug" and "Feature-request" are an *issue status* as far as the tracker is concerned. This allows both bugs and features to set *Type*.
"Type" refers to something in or about Python itself, rather than something in the tracker. (Something the issue *addresses* in python.) That description fits well with the items already there.
An open status is the same as (not (closed-committed or closed-rejected)).
The placement of some items could be better. Status, and priority would fit better in the classification section. Stage would fit better in the process section.
Cheers, Ron
participants (9)
-
Alexander Belopolsky -
Antoine Pitrou -
Eli Bendersky -
Georg Brandl -
Michael Foord -
Nick Coghlan -
Ron Adam -
skip＠pobox.com -
Éric Araujo