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:

  1. Bug is reported (by core dev or external user)
    • STATE <= NEW

  2. Bug is triaged (during weekly meeting, if not earlier)
    • assigned lead developer

    • (NOT assigned a target release ... that happens only when STATE <= ACCEPTED)

  3. Bug gets preliminary review by some group member
    • if it is judged eligible for fixing:
      • reviewer sets target release (as next release, not a future release)
      • reviewer verifies or changes lead developer
      • reviewer assigns provisional risk profile and testing requirements

  4. When STATE == ACCEPTED, assigned developer fully assess work and manages estimates for:
    • timing and difficulty
    • target release
    • risk profile and testing requirements

  5. Assigned developer implements fix
    • code is checked in to development branch
  6. Assigned developer reassigns issue to a reviewer

    • set "assignee" field to reviewer (Note: the "reviewer" field doesn't notify the reviewer via e-mail, so we don't use it)
  7. Reviewer checks code and reassigns to original developer
    • check code out from development branch
    • for features, use Quality Circles document to verify code meets requirements and fulfills quality aspects ... document findings in Quality Circles table
    • if good: STATE <= REVIEWED ... if the change is for the current release, developer cherry picks 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

    • set "assignee" field to original developer
  8. Assigned developer sets STATE <= CLOSED

  9. As part of release planning:
    • coordinate testing

*** Note that a target version should be assigned iff STATE == ACCEPTED or beyond. Otherwise STATE should be TRIAGED. ***

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

Cytoscape_3/CoreDevelopment/BugReviewProcess (last edited 2017-09-26 17:17:24 by bdemchak)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux