Does a change set associated with 2 work items require approval in both before deliver?
We currently have 2 project areas, one for new Development, one for the Service of released versions.
When a defect is found in a released version a fix is developed and checked in to a change set in the Service project area. The change set is associated with a work item in the Service project area and put up for review.
Another work item is raised in the Development project area to port the fix. Ideally the development fix can reuse the original change set, perhaps requiring a merge change set. The change set is associated with the Development work item too. Note, this requires either the change set owner or a JazzAdmin to perform the assocation, see https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=57870
For one of the 2 products I support the Dev and Service fix is normally done by the Service engineer. In the other the Dev fix is done by a developer who is not the person who implemented the fix for service.
The change set is now associated with 2 work items, one in each project area.
The Service engineer gets his work item approved and goes to deliver, but finds that it is refused because it fails the "Require Work Item Approval" precondition.
Presumably the implementation is such that ALL associated work items require approval, even those work items in other project areas?
What options do we have?
1) Enable the user to overrule the Require Work Item Approval precondition. I favour this but some people fear users taking advantage to avoid code reviews.
2) Get the change set owner or a JazzAdmin to temporarily remove the Development association so that the deliver succeeds, then re-associate
3) Make the Service delivery wait until the Development work item is also reviewed. But Service want to close out their work and do not want to wait.
4) Do not attempt to reuse change sets and create "duplicate" change sets instead. This makes future change sets that affect the files un-reusable due to "gaps" etc and I think we want to avoid this where possible
5) Use one work item to perform the Service and Development work. This doesn't work well when different people are doing the Service and Development fixes, and it somewhat forces the work to happen at the same time because the Service side want to close their work item when their half is done.
Any suggestions?
When a defect is found in a released version a fix is developed and checked in to a change set in the Service project area. The change set is associated with a work item in the Service project area and put up for review.
Another work item is raised in the Development project area to port the fix. Ideally the development fix can reuse the original change set, perhaps requiring a merge change set. The change set is associated with the Development work item too. Note, this requires either the change set owner or a JazzAdmin to perform the assocation, see https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=57870
For one of the 2 products I support the Dev and Service fix is normally done by the Service engineer. In the other the Dev fix is done by a developer who is not the person who implemented the fix for service.
The change set is now associated with 2 work items, one in each project area.
The Service engineer gets his work item approved and goes to deliver, but finds that it is refused because it fails the "Require Work Item Approval" precondition.
Presumably the implementation is such that ALL associated work items require approval, even those work items in other project areas?
What options do we have?
1) Enable the user to overrule the Require Work Item Approval precondition. I favour this but some people fear users taking advantage to avoid code reviews.
2) Get the change set owner or a JazzAdmin to temporarily remove the Development association so that the deliver succeeds, then re-associate
3) Make the Service delivery wait until the Development work item is also reviewed. But Service want to close out their work and do not want to wait.
4) Do not attempt to reuse change sets and create "duplicate" change sets instead. This makes future change sets that affect the files un-reusable due to "gaps" etc and I think we want to avoid this where possible
5) Use one work item to perform the Service and Development work. This doesn't work well when different people are doing the Service and Development fixes, and it somewhat forces the work to happen at the same time because the Service side want to close their work item when their half is done.
Any suggestions?
Accepted answer
I don't think there's a way to configure the advisors to avoid this kind of problem. Perhaps it would be better to create the development work item after the service work item has been delivered? I can't think of any other suggestions than what you have already thought of to get around this issue short of writing your own advisor that also takes the work item's project area into consideration.