Trac ticket workflow

Workflow

Here is an approximate common path, subject to circumstances. Set the 'Action Needed' field in Trac sequentially to:

 (everyone should):
 reproduce       --  first we need to know how to reproduce your issue
 diagnose        --  then its root cause needs to be diagnosed
 design          --  at which time we can design...
 code            --  and code a fix.
 review          --  to ship the fix, we need to review it,
 testcase        --  write a test case for it,  
 
 (module maintainers should):  
 package         --  and package it up as an RPM, an activity, etc.
 add to build    --  then package needs to be added to a development build
 
 (everyone should):
 test in build   --  and the packaging needs to be tested.
   
 (during change control):
 approve for release --  get approval to add the package to a stable build stream (stable builds only)
 add to release  --  approved changes need to be committed
 test in release --  and retested at least once...
 
 (everyone should):
 qa signoff      --  some developers will want QA to review their work... (optional)
 finalize        --  before being added to the release notes
 no action       --  and closed.

General Notes

• After testing in a build, the developer tags the bug with the results, e.g.:

 joyride-2126:-    or   joyride-2126:+
 ( '-' means bad result, try again, whereas '+' means good result )

• The purpose of the finalize state is for the release team to provide any user-facing documentation or to conclude that no documentation is necessary.
• The workflow can be exited early by resolving a ticket as 'worksforme', 'invalid', etc.
• At various times, someone (e.g. the developer or the release team) may need an answer to a question. In this event, the ticket's next action should be set to 'communicate'.
• Finally, the other 'Action Needed' states can be used to describe ignorance about what sort of action is needed. The regular Trac triage process will be responsible for pushing these tickets along.

Change Control

We enter change-control near the end of each release (e.g. 8.2.0 release schedule). When we enter change control, the ticket workflow expands to include the 'approve for release', 'add to release', and 'test in release' actions.

In order to pass the 'approve for release' action, you are expected to provide several of:

packages

a complete list of the packages (in source: (E)NVR form, e.g. koji: rainbow-0.7.20.fc9) which must be included to effect your change.

changelog

a nice human-readable description of your change including citations of tickets that will need to be updated as it is processed.

testcases

checkable test cases in either the |TestCase| Sugar style, the Systematic testing style, or the Tinderbox style.

risk assessment

an explanation, if convenient, of what risks are incurred by accepting your change.