Trac ticket workflow: Difference between revisions
(Add the new 'approval for release' state.) |
mNo edit summary |
||
| Line 6: | Line 6: | ||
design -- at which time we can design... |
design -- at which time we can design... |
||
code -- and code a fix. |
code -- and code a fix. |
||
review -- to ship the fix, we need to review it, |
review -- to ship the fix, we need to review it, |
||
testcase -- write a test case for it, |
testcase -- write a test case for it, |
||
package -- and package it up as an RPM, an activity, etc. |
package -- and package it up as an RPM, an activity, etc. |
||
add to build -- then package needs to be added to a development build |
|||
add to build -- then package needs to be added to a build |
|||
test in build -- and the packaging needs to be tested. |
test in build -- and the packaging needs to be tested. |
||
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 |
|||
qa signoff -- some developers will want QA to review their work... |
qa signoff -- some developers will want QA to review their work... |
||
finalize -- before it is added to the release notes |
finalize -- before it is added to the release notes |
||
| Line 20: | Line 23: | ||
( '-' means bad result, try again, whereas '+' means good result ) |
( '-' means bad result, try again, whereas '+' means good result ) |
||
:I presume this is after the "test in build" state, which I presume means the developer who coded the fix tested it in a build. That could be clearer. Then, what does the developer do? Just set it to "qa signoff"? Assign it to some QA person? At what point does it get tagged into the 8.2 release stream, and should it be assigned to someone to ensure that? --[[User:Morgs|morgs]] 09:59, 17 July 2008 (UTC) |
|||
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 purpose of the finalize state is for the release team to provide any user-facing documentation or to conclude that no documentation is necessary. |
||
Revision as of 19:37, 3 September 2008
Here is an approximate common path, subject to circumstances. Set the 'Action Needed' field in Trac sequentially to:
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, package -- and package it up as an RPM, an activity, etc. add to build -- then package needs to be added to a development build test in build -- and the packaging needs to be tested. 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 qa signoff -- some developers will want QA to review their work... finalize -- before it is added to the release 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.