Code Review: How do you address Must-Fix issues without a new change set?
Our team is exploring the new Code Review feature in RTC v 6.x. When there are must fix issues, we cannot figure out if there's a way to change the code in the current change set. If we open the local file to edit it, we then have two change sets. Is there a way to edit the checked in change set so we don't have to deal with multiple change sets that haven't been delivered? Or is there a good process to follow to handle changes we make based on code review comments?
|
Be the first one to answer this question!
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.
Comments
Why are you avoiding creating a second change set?
We thought it would be a cleaner process if we could open the files in the checked-in change set and address the issues. When you open the local copy, you end up with a second change set, so you have to deliver both even though the first had must-fix issues. We couldn't find an elegant way around that.
A review is based on a work item. Having multiple change sets associated with a single work item is very normal in RTC, so there is no reason to try to avoid it (for example, if you are making changes to more than one component, then you will have to have multiple change sets).
I understand multiple components = multiple change sets. What I don't understand is that I have a completed change set that I don't want to deliver because it has must-fix issues. To correct them, I need to create a second change set for the same component. The first one with the issues is not replaced, instead I have two change sets, one with issues and one with the issues corrected. However, I have to deliver both to complete the process and when I do, I've now delivered code with errors to the stream immediately followed by code that corrects the errors....which I guess is okay, but I would think you'd want to replace the first change set with a corrected one or remove the first and check in the corrected one. That just seems clunky to me.
A change set needs to be completed before you can do a code review. Once they are completed you can't change them any more. if you could, users could basically also sneak changes under approved stuff and - from a regulatory perspective do basically forgery. All your process accuracy would be compromised. I think that is much more clunky.
In this context, how yould you know what the additional change is that fixes the reviews compaints?