I was wondering how Dragnet supports branches.
For example,
-an issue is found in version 1.0 which is in production. An incident is logged
-The incident is fixed in 1.0
-Source changes are merged into main branch
How does QA track that the incident from 1.0 needs to be retested in the main branch(hence 2.0)? Does Dragnet clone the incident?
How Does Dragnet Support Branches?
Moderator: SourceGear
Dragnet doesn't automatically create another bug. Someone would need to manually enter another bug with the new milestone of 2.0.
Or you could reopen the bug, change the milestone and QA could re-verify. You'd maintain all the bug history so it was clear how this had been handled.
Or you could reopen the bug, change the milestone and QA could re-verify. You'd maintain all the bug history so it was clear how this had been handled.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
Scott Prugh
Feature Request: Incident Tracking to branches
This would not necessarily work. In the simplest case concurrent development would break this approach as the case would need to have different states.
I think this really needs to be part of the tracking system at the low level. For even trivial branching scenarios, incidents need to be tied to branches and need to have their own lifecycle tied to that branch. This allows QA to clone/associate an incident to a particular branch of code, and determine if/when it should be fixed. In some cases, the incident may be fixed Indirectly, or no longer applicable because of sunsetted or changed functionality. Either way, audits need to be run on all forward branches(or just the main branch) and decisions made as to which incidents get fixed. In reality, the merge will "fix" the incident, but you still want to test that the fix made it and audit such. Ideally, the incident id would stay the same and an incident would support a one-to-many association with different branches. A simple hard clone(a new incident) works but gets unwieldy because you have to track multiple incident ids. It would be nice to always refer to a case/incident and its branch or referring to a case would show the case across associated branches/milestones.
I can discuss this req a bit more if you would like.
Regards,
-Scott
I think this really needs to be part of the tracking system at the low level. For even trivial branching scenarios, incidents need to be tied to branches and need to have their own lifecycle tied to that branch. This allows QA to clone/associate an incident to a particular branch of code, and determine if/when it should be fixed. In some cases, the incident may be fixed Indirectly, or no longer applicable because of sunsetted or changed functionality. Either way, audits need to be run on all forward branches(or just the main branch) and decisions made as to which incidents get fixed. In reality, the merge will "fix" the incident, but you still want to test that the fix made it and audit such. Ideally, the incident id would stay the same and an incident would support a one-to-many association with different branches. A simple hard clone(a new incident) works but gets unwieldy because you have to track multiple incident ids. It would be nice to always refer to a case/incident and its branch or referring to a case would show the case across associated branches/milestones.
I can discuss this req a bit more if you would like.
Regards,
-Scott