Trac ticket workflow

  This page is monitored by the OLPC team.

  For Developers

This page discusses the workflow which Trac tickets move through. It presents the workflow states, a toy user story, and a brief discussion of the requirements which must be satisfied to move tickets through a delicate portion of the workflow.

Workflow States

Here is an approximate common path, subject to circumstances, followed by a toy user story.

A Trac ticket's position in the workflow is recorded in its Action Needed field. This field can contain the following values:

 (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...
 
 (as needed):
 qa signoff      --  some developers will want QA to review their work... (optional)
 finalize        --  before being added to the release notes
 no action       --  and closed.

Approval for Release

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:

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.

(optional) risk assessment

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

User Story

Characters

Anonymous Alice -- generic (possibly minimally skilled) Trac user.

Terry Ticket-Herder -- ticket herder who watches incoming tickets and improves their quality.

Carol Coder -- coder who diagnoses, designs, codes, and reviews code.

Mark Maintainer -- module maintainer (packager) aggregates code and pushes it into build streams (i.e. into Fedora or Joyride).

Release Rob -- release team member who approves requests to modify a stable build stream.

Bill Builder -- build team member

Quality Assurance -- QA team member

Story

1. Anonymous Alice observed curious behavior while exploring the system. She records it in Trac but does not set the next_action field or sets it to unknown.
2. Terry Ticket-Herder decides Alice's reported behavior is significant but doesn't know how to reproduce it so he changes the next_action to reproduce to indicate his need for instructions on how to reproduce the issue.
   • Terry might instead have closed Alice's ticket as invalid, worksforme, etc or have sent it on to a later state if Alice wrote a particularly good ticket.
   • If necessary, Terry would also fill in the Milestone, Component, Keywords, and CC fields to conform to our Trac conventions.
3. Once Alice's behavior can be reproduced, it can be diagnose[d] by Carol Coder (probably with help from Alice).
4. Carol will eventually propose a design that she thinks will resolve the issue.
5. Carol will code to her design and will seek review of her work. She will also write a testcase.
6. When all is in order, Carol or Mark Maintainer will package the changes and add them to a development build (in the add to build state).
7. When built in Joyride, Carol or Mark will test in build.
   • If the test fails, then the tester may remand the issue to an earlier state and owner; otherwise, the tester should advance the ticket to the next state (see below).
   • Test results should be recorded according to the Trac conventions (e.g as a keyword like joyride-2230:+ for a 'pass' or 8.2-757:- for a 'fail').
8. During change control, changes must pass through three additional steps:
   1. Changes cannot be committed to the stable build stream without meeting basic requirements. Release Rob will regularly review tickets in the approval for release state.
   2. Approved changes will be sent to the Bill Builder in the add to release state.
   3. Once Bill updates the stable build stream, he will place the ticket in the test in release state for further testing by Alice, Carol, or another friend.
      • After being tested as fixed in a release-stream build, issues should be pushed through some of the qa signoff, finalize, or no action states. See below.
9. Occasionally, an issue may require test facilities beyond those available to ordinary developers and testers or may be so important that it requires additional systematic testing. Such issues can be pushed, at anyone's discretion, through the qa signoff state where Quality Assurance will examine them and pass them on.
10. Rob will document tickets which reach the finalize state in the Release Notes.
11. Tickets will eventually require no action.
    • Rob is responsible for closing user-facing issues which result in changes to the build or work-arounds.
    • Other issues can be closed by anyone when they cease to be relevant to the release process.