Trac ticket workflow: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(30 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{OLPC}}
{{developers}}

This page discusses the workflow which [[Trac]] tickets move through. It presents the [[#Workflow States|workflow states]], a toy [[#User Story|user story]], and a brief discussion of the [[#Approval for Release|requirements]] which must be satisfied to move tickets through a delicate portion of the workflow. Questions about this workflow can be recorded on the [[Talk:Trac ticket workflow|discussion page]]. Finally, be aware that this workflow differs from any previous one and will probably change again during the this release cycle.

== Workflow States ==
== Workflow States ==


Line 18: Line 23:
(everyone should):
(everyone should):
'''test in build''' -- and the packaging needs to be tested.
'''test in build''' -- and the packaging needs to be tested,
even though a build might not yet exist for this.
(during change control):
(during change control):
Line 25: Line 31:
'''test in release''' -- and retested at least once...
'''test in release''' -- and retested at least once...
(everyone should):
(as needed):
'''qa signoff''' -- some developers will want QA to review their work... (optional)
'''qa signoff''' -- some developers will want QA to review their work... (optional)
'''finalize''' -- before being added to the release notes
'''finalize''' -- before being added to the release notes
Line 33: Line 39:
== Approval for Release ==
== Approval for Release ==


We enter change-control near the end of each release (e.g. [[8.2.0#Schedule|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.
We may enter change-control near the end of a release. 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:
In order to pass the 'approve for release' action, you are expected to provide:
Line 41: Line 47:
; changelog
; changelog
: a nice human-readable description of your change including citations of tickets that will need to be updated as it is processed.
: a nice human-readable description of your change including citations of tickets that will need to be updated as it is processed.
; test cases
; testcases
: checkable test cases in either the <tt>|TestCase|</tt> Sugar style, the [[Systematic testing]] style, or the [[Tinderbox]] style.
: checkable test cases in either the <tt>|TestCase|</tt> Sugar style, the [[Systematic testing]] style, or the [[Tinderbox]] style.
; test results
: the results of executing your test cases on a development build (or after having installed your packages on release-stream build)
; (optional) risk assessment
; (optional) risk assessment
: an explanation, if convenient, of what risks are incurred by accepting your change.
: an explanation, if convenient, of what risks are incurred by accepting your change.




== General Notes ==
== User Story ==


=== Characters ===
* 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 )


:''Anonymous Alice'' -- generic (possibly minimally skilled) Trac user.
* 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.
:''Terry Ticket-Herder'' -- ticket herder who watches incoming tickets and improves their quality.
* The workflow can be exited early by resolving a ticket as 'worksforme', 'invalid', etc.
:''Carol Coder'' -- coder who diagnoses, designs, codes, and reviews code.
* 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'.
:''Mark Maintainer'' -- module maintainer (packager) aggregates code and pushes it into build streams (i.e. into [[Developer/Fedora|Fedora]] or [[Build system#Instructions for use|Joyride]]).
* 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.
:''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 ===


# ''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'''.
== User Story ==
# ''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.
# Alice observed curious behavior while exploring the system. She records it in Trac but does not set the <tt>next action</tt> field.
#* 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]].
# Bob decides Alice's reported behavior is erroneous 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.
# Carol can reproduce Alice's behavior but doesn't understand its root cause so she changes the ticket's <tt>next action</tt> to ''diagnose''.
# 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.
# Don diagnoses Alice's behavior and changes the <tt>next action</tt> to ''design'' to indicate that he is needs a ''design''.
# Carol will '''code''' to her design and will seek '''review''' of her work. She will also write a '''testcase'''.
# Eve provides a design and changes the <tt>next action</tt> to ''code''.
# 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).
# Frank implements the design and changes the <tt>next action</tt> to ''review''.
# When built in Joyride, Carol or Mark will '''test in build'''.
# Geraldine reviews Frank's changes and asks for a ''testcase''.
#* 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).
# Harry accepts merges the reviewed changes into a ''package''.
#* 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').
# Ia adds Harry's package to a development build and requests that the package be checked by setting <tt>next action</tt> to ''test in build''.
# ''During change control'', changes must pass through three additional steps:
# John tests the development build Ia triggered. He records his results and may send the issue back to an earlier state (e.g. for a fresh diagnosis) or may send it forward into one of ''approve for release'' (if change control is active), ''qa signoff'', ''finalize'', or ''no action''.
## 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.
#* If the next action is ''approve for release'', then the release manager, Karl, will make sure the [[#Approval for Release|requirements for approval]] are satisfied and will push the ticket back to an earlier state (if they are unsatisfied), will slip the issue into the next release, or will approve the changes. If approved, they will go into the ''add to release'' state, then the ''test in release'' state, then either a
## Approved changes will be sent to the ''Bill Builder'' in the '''add to release''' state.
#* Lily from QA retests the issue and moves the ticket to ''finalize'' because she thinks that the release notes need to be updated.
#* Mark updates the release notes and, at last, sets <tt>next action</tt> to ''no action'' and resolves the ticket as ''fixed''.
## 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:Trac]]
[[Category:Procedures]]

Latest revision as of 23:03, 13 May 2010

  This page is monitored by the OLPC team.

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 any previous one and will probably change again during the this release cycle.

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,
                           even though a build might not yet exist for this.
   
 (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 may enter change-control near the end of a release. 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.
test cases
checkable test cases in either the |TestCase| Sugar style, the Systematic testing style, or the Tinderbox style.
test results
the results of executing your test cases on a development build (or after having installed your packages on release-stream build)
(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.