RTC Defects for multiple streams?
Are there best practices for logging and managing defects in multiple streams?
We have a maintenance stream for v1.0 and a development stream for v1.1 We thought having less items to manage was better to track both streams in the same defect and to flag defects that are to be part of a maint. release we would use tags instead of creating a duplicate defect for each. This prevents the problem of triaging many items twice, and having relevant defect info added to one but not the other copy, but may pose a problem when querying and when a fix for maint. is not done at the same time as a fix for the dev stream. We figure all dev teams have struggled with the best way to handle this? Are there any supporting documents or material that describe what Jazz RTC dev envisioned for this? How are other teams handling this? |
5 answers
|
I did find an older post on the same subject, but still hope for some replies.
https://jazz.net/forums/viewtopic.php?t=2573 I hope the Jazz dev team can share their vision in this regard too. Thanks for any information or contribution to this topic. Steve |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 22 '09, 12:52 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One approach is to create a "defect" workitem for the defect, and then
create a separate "task" workitem for each stream in which that defect is to be fixed. The "defect" captures the problem, and the "tasks" capture the work done in a particular stream to solve that problem. You can look at the stories in the Rational Change Management category, to see how we are planning on providing support for that scenario in the context of a RTC/CQ integration scenario (where requests are created in CQ, and tasks are created in RTC). Cheers, Geoff hyde wrote: Are there best practices for logging and managing defects in multiple |
hyde wrote:
We thought having less items to manage was better to track both In our team, we assign the defect to the earliest applicable milestone, and port the changes (either by accepting and merging, or patching) into more recent streams, noting in the work item if there is something significant of how this work was completed in a particular branch. As time goes on, and our release streams diverge further and further, I could see us moving towards a structure along the lines of what Geoff wrote. Regards, JohnC SCM Server |
|
Our initial goal is to keep it simple and i believe that less defects to manage is better (is this true?)
We are proposing the same approach as John's, but also using tags to flag when a defect is to be applied to maintenance too ( this seems to be along the lines we see RTC and RQM dev doing?) Some possible exceptions /questions; - what do we do when a defect fails validation in one of the streams it is supposed to be fixed in? How do you re-open it in one but not the other? if the iteration is not 'done' because a defect is not 'closed' in all streams, how can we report on this? - how does one state /resolution in the defect accurately reflect all the streams' status? Perhaps using approvals for this? We are still looking into how this could be set up. |
hyde wrote:
Our initial goal is to keep it simple and i believe that less defects It depends. Managing multiple work items when each work item serves a single purpose will in many cases be simpler than managing one work item that serves multiple purposes. If it is easy to get the changes from one stream to another, then it is probably simplest to go with one work item. If propagating the changes takes some effort, or if the changes don't work in one of the streams, then it's probably best to use multiple work items. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.