[Python-Dev] "unit test needed"

Ron Adam rrr at ronadam.com
Tue Jan 11 22:36:43 CET 2011



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



More information about the Python-Dev mailing list