Trac ticket workflow: Difference between revisions
Jump to navigation
Jump to search
(→Story) |
|||
| Line 12: | Line 12: | ||
. |
|||
=== Story === |
|||
# ''Anonymous Alice'' observed curious behavior while exploring the system. She records it in Trac but does not set the <tt>next_action</tt> field or sets it to '''unknown'''. |
|||
# ''Terry Ticket-Herder'' decides ''Alice's'' reported behavior is significant but doesn't know how to reproduce it so he changes the <tt>next_action</tt> to '''reproduce''' to indicate his need for instructions on how to reproduce the issue. |
|||
#* Terry might instead have closed Alice's ticket as <tt>invalid</tt>, <tt>worksforme</tt>, 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 <tt>Milestone</tt>, <tt>Component</tt>, <tt>Keywords</tt>, and <tt>CC</tt> fields to conform to our [[Trac conventions]]. |
|||
# Once Alice's behavior can be reproduced, it can be '''diagnose'''[d] by ''Carol Coder'' (probably with help from Alice). |
|||
# Carol will eventually propose a '''design''' that she thinks will resolve the issue. |
|||
# Carol will '''code''' to her design and will seek '''review''' of her work. She will also write a '''testcase'''. |
|||
# 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). |
|||
# 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 <tt>joyride-2230:+</tt> for a 'pass' or <tt>8.2-757:-</tt> for a 'fail'). |
|||
# ''During change control'', changes must pass through three additional steps: |
|||
## Changes cannot be committed to the stable build stream without meeting [[#Approval for Release|basic requirements]]. ''Release Rob'' will regularly review tickets in the '''approval for release''' state. |
|||
## Approved changes will be sent to the ''Bill Builder'' in the '''add to release''' state. |
|||
## 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. |
|||
# ''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. |
|||
# Rob will document tickets which reach the '''finalize''' state in the [[Release Notes]]. |
|||
# 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. |
|||
[[Category:Trac]] |
|||
[[Category:Procedures]] |
|||
Revision as of 19:59, 29 December 2008
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. Questions about this workflow can be recorded on the discussion page. Finally, be aware that this workflow differs from the previous one and will probably change again during the 9.1.0 release cycle.
User Story
.