Cytoscape Wiki
Bug Review Process
This article describes developer activities and how they are tracked through Redmine.
The Redmine state is represented as STATE, which can take on the following values: {NEW, TRIAGED, ACCEPTED, IN PROGRESS, IN REVIEW, REVIEWED, CLOSED, FEEDBACK, RESOLVED, REJECTED}.
A typical state sequencing would be NEW -> TRIAGED -> ACCEPTED -> IN PROGRESS -> IN REVIEW -> REVIEWED -> CLOSED as described below:
- Bug is reported (by core dev or external user)
STATE <= NEW
- Bug is triaged (during weekly meeting, if not earlier)
- assigned lead developer
- possibly assigned target release
STATE <= TRIAGED
- Bug gets preliminary review by some group member
- if it is judged eligible for fixing:
- reviewer sets target release
- reviewer verifies or changes lead developer
- reviewer assigns provisional risk profile and testing requirements
STATE <= ACCEPTED
- if it is judged eligible for fixing:
- When STATE == ACCEPTED, assigned developer fully assess work and manages estimates for:
- timing and difficulty
- target release
- risk profile and testing requirements
STATE <= IN PROGRESS
- Assigned developer implements fix
- code is checked in to development branch
- Assigned developer reassigns issue to a reviewer
STATE <= IN REVIEW
- Reviewer checks code and reassigns to original developer
- check code out from development branch
if good: STATE <= REVIEWED ... if the change is for the current release, cherry pick it into the current hotfix branch
if more work needed: STATE <= ACCEPTED and return to developer ... developer and reviewer can agree to withdraw checkin from development branch
Assigned developer sets STATE <= CLOSED
- As part of release planning:
- coordinate testing
- cherry pick code into trunk
Cherry picking
git checkout FIX-BRANCH git cherry-pick -x DEV-COMMIT-HASH-CODE
Other Redmine States
FEEDBACK = waiting for user reply ... could follow TRIAGED or ACCEPTED, and could precede ACCEPTED, CLOSED, or REJECTED
RESOLVED = unknown function
REJECTED = closed and not fixed