Originally published on 2011-10-08 09:13
I find that one of the most difficult things about CIM is having to un-learn the things which were true in Defect Manger. Defect triage is much different in CIM. While it makes perfect sense once you understand it, it can be difficult to get the hang of it at first. Here's my attempt to make it clearer.
Starting from the beginning ...
1) When the analysis runs, it creates 'Source Defect Instances'. These are particular instances of a defect, in a particular file and at a particular line.
2) When you commit defects to CIM, the 'Source Defect Instances' are merged into CIDs and 'Stream Defect Instances'.
a) CIM 5.x will merge all 'Source Defect Instances' into the same CID, as long as the three merge fields are the same. The three merge fields are: the (possibly mangled) function name; the checker name; and the contents of the 'extra' field.
In CIM 5.x, CIDs are shared across the entire installation of CIM. This means that if *any* defect in *any* stream or *any* project matches the three values <function name/checker name/extra field contents>, it will be assigned the same CID. This is in contrast to Defect Manager 4.x, which would assign a new CID to each defect instance in a different product.
Put another way, in Defect Manager CIDs were assigned based on matching the four values <function name/checker name/extra field contents/product>, while in CIM CIDs are assigned based *only* on the three values <function name/checker name/extra field contents>.
b) Multiple 'Source Defect Instances' which occur within a single stream are merged into a 'Stream Defect Instance'. You can think of a 'Stream Defect Instance' as a <stream,CID> pair.
Note that because of the merging algorithm described in (a) above, there may be multiple Stream Defect Instances with the same CID. If there are, these are (conceptually) instances of the same defect which occur in different streams.
3) In CIM 5.x, triage information is stored at the *Stream Defect Instance* level. By "Triage Information", I mean the defect's status, classification, action and owner information, as well as any comments or history associated with the defect.
This means that if you have multiple Stream Defect Instances for a single CID, each one can have a different disposition and be assigned to a different owner. This makes sense: if (for example) your two streams correspond to a Development branch and a Production branch, you might have different developers assigned to handle the same defect instance: one for the Development branch and one for the Production branch. Similarly, you might choose to fix a defect in the Development branch, but mark it as Ignore in the Production branch, if you decided that fixing that defect would be too destabilizing for the production release.
4) CIM 5.x allows you to construct "Projects", which are the union of a set of streams.
5) Within a Project, defects are displayed as 'Merged Defects'. A 'Merged Defect' is the combination of all of the 'Stream Defect Instances' with the same CID that are part of this Project. The 'Merged Defect' is what you see when you view an individual defect at the Project level within CIM.
6) The display of triage data for a Merged Defect depends on the state of the triage data in the Stream Defect Instances that it comprises.
Briefly: if the values of a triage field are identical in all of the Stream Defect Instances, then the Merged Defect will display that value for that field. If the values of the triage field differ betwen the Stream Defect Instances, you'll see "Various" as the value of that triage field.
For example, suppose you have a Project "Alpha" which is made up from streams A, B, and C, you are looking at CID 10001 within that project.
If the value of "Action" is "Fix Required" for CID 10001 in stream A, B, and C, then the Merged Defect will display "Fix Required" as the value of "Action". If the value of "Action" is "Fix Required" in streams A and B, and "Ignore" in stream C, then the Merged Defect will display "Various" as the value of "Action".
Note that this does not apply to the "Status" field, which will always display the "most actionable" status of all the Stream Defect Instances that make up the Merged Defect.
7) 'Merged Defects'.are highly dynamic. If you have a Project Alpha which is made up from streams A, B, and C, then the display of triage data for CID 10001 in Alpha is constructed on-the-fly from the triage data for the Stream Defect instances for streams A, B, and C.
If you add a stream D to project Alpha, then go to view CID 10001 again, now the Merged Defect triage data will be constructed from the Stream Defect Instances for *four* streams. If the triage data in the Stream Defect Instance in stream D for CID 10001 does not match that in the other three streams, the display of the triage data will change.
Just to be clear: this means that the displayed values of a Merged Defect can change by changing the Project definition - without you doing *any* triage to any defect!
8) When you apply triage to a Merged Defect, what you are really doing behind the scenes is applying the same triage changes to all the Stream Defect Instances that make up the Merged Defect.
Continuing with the example above: if you were to set the value of "Action" in the Merged Defect for CID 10001 to "Ignore", what CIM will do, by default, is to apply that triage to all of the Stream Defect Instances that make up that Merged Defect.
9) If you prefer, CIM's Advanced Defect Editor will display and allow you to edit the triage data at the Stream Defect Instance level.
10) You can control which streams get affected by triage to a Merged Defect by setting the default "Scope of Triage". This is defined at the Project level.
The Scope of Triage is represented by two strings separated by a slash. The first represents the projects that the triage applies to: the second represents the streams that the triage applies to. You can use '*' as a wildcard. The default Scope of Triage is $PROJECTNAME/*, which means "Apply this triage to all of the streams in this project". For project Alpha, the default Scope of Triage would be "Alpha/*".
11) You edit the default Scope of Triage at the project level. For example, if you set the default Scope of Triage to be "Alpha*/*", CIM by default would apply the triage for CID 10001 to every Stream Defect Instance with CID 10001 in every stream that was part of a Project whose name began with "Alpha".
If you set the the default Scope of Triage to "*/*", CIM would by default apply the triage to every Stream Defect Instance with CID 10001 in the entire Defect Database.
I hope this clarifies things for folks out there. I think this is a very powerful and flexible method of dealing with triage data. Unfortunately, it comes at a price of being more complex and requiring some work to understand.
Originally published on 2010-05-25 10:00
This information is very helpful and will assist us in understanding how CIM works. I still have some fundamental issues that elude my understanding. For example I have to keep going back to how we use Clearcase for source control and how it will relate to CIM. Lets say we have two disjoint products and the source files for Product A are located in windows drive X:\src and the source files for Product B in Y:\src. In the reading of CIM and from the forum postings I gather that CIM does not care about file paths or even file names. That being said, lets assume that we have a file called Database.c in both X:\src\Database.c and Y:\src\Database.c and both of these files contain a function
Furthermore lets assume these two functions have nothing in common other than the coincidence of having the same signature for the function (and file) name. Assume we create CIM project ProjectA with all the defaults and ProjectB with all the defaults. We build X:\ files and commit to stream ProductA, and build Y:\ files and commit to stream ProductB.
How will CIM view these two functions? I am concerned that CIM will attempt to treat these as varients of each other in when (in this example) in fact they are completely different.
Originally published on 2010-05-25 19:48
The answers to your questions are implied by the algorithm in (2) above.
Here's what will happen:
1) If you have two Source Defect Instances which were found by the same checker, have the same 'extra' field value, and occur in two functions with the same name, CIM will merge them into a single CID. This will happen even if they are in two files with different names, or in two different build streams.
2) Because these two source defect instances have been committed to two different streams, there will be two separate Stream Defect Instances.
3) If the two streams are assigned to two separate projects: that is, stream A is only assigned to project A, and stream B is only assigned to project B, AND if both project A and project B have the default triage scope, then any change you make to the Merged Defect in project A will not affect the status of the Merged Defect in project B.
4) If, on the other hand, you have a third project -- call it project C -- which has *both* stream A and stream B assigned to it, then the Merged Defect for that CID in project C will consist of the two Stream Defects, even though they have nothing in common other than their function names (assuming C/C++) or function signatures (assuming Java).
In other words: yes, the increased flexibility and power of the stream/project model *will* allow you to shoot yoursefl in the foot. You can keep this from happening by making sure that the two streams never appear in the same project.