Appendix: EMI Tracker Mappings

This is an appendix to the Change Management Policy. It presents the mappings of the different tracking tools used by EMI product teams to track RfCs. It shows the mapping of the required field according to the Change Management Policy to the corresponding field in the PT tracker tool.

1. RfC field mapping

The following table presents the mapping of the different EMI trackers to the mandatory RfC fields:

RfC Field	Definition	ARC Bugzilla	dCache RT	gLite Savannah	UNICORE SourceForge	StoRM Redmine	MPI Trac	Registry/CANL GitHub
Unique Identifier/URL	a URL pointing to a description of the RfC. If the RfC concerns a security vulnerability the URL should point to a private page. The URL acts also as a unique identifier for the RfC.
Associated GGUS tickets	If applicable, one or more URLs pointing to GGUS tickets that have caused the opening of this RfC	URL	GGUS_ID	GGUS reference URL	GGUS URL added in the Details field as free text.
Affected Product	EMI Product List as specified in DNA1.3.2	Product	Product		Category field exists but doesn't match DNA1.3.2	Affected Product	Component
Affected EMI Major release	EMI major release affected by the RfC	It can be mapped to an ARC release since there's 1:1 correspondence to EMI releases	EMI	Baseline Release
Affected Platforms	Whether the RfC is platform-specific and, if so, which are the affected platforms
Priority	Immediate, High, Medium or Low	1 (Immediate) 2 (High) 3 (Medium) 4 5 (Low)	Priority numerical field	Immediate, High, Medium, Low	1 2 (Low) 3 4 5 (Medium) 6 7 8 (High) 9 (immediate)	Immediate, High, Normal, Low	Low, Medium, High, Immediate
Defect vs Feature	Whether the RfC is to fix a defect or to introduce a new feature.	One severity level is feature request	Two different Queues, one for defect and one for feature.	Severity field exist but not sure PTs use it properly to differentiate defect and features.	Defects are in the Bug tracker, New features are in the Enhancements and Improvements and Feature Requests tracker	Bug vs Feature	Defect vs Feature
Detection Area	The context in which the version of the component affected by the change is available. Possible values are production, testing and development	Implied by release version. Development has a special release tag CVS, and Testing are release candidate versions. Everything else is Production	One possible value only: Development	Bug Detection Area	One possible value only: Development
Target EMI major release	The target EMI major release where the RfC will be available.	ARC release field it can be mapped to EMI release 1:1	field can be mapped to EMI release 1:1	Release	UNICORE release field it can be mapped to EMI release 2

For the mandatory fields that are not present in the trackers by default, middlewares must provide the missing information in the XML file needed by SA2.3 to calculate metrics.

2. RfC states mapping

The following table presents the mapping of the different EMI trackers to the mandatory RfC states.

State	ARC State Description	dCache State Description	gLite State Description	UNICORE	StoRM State Description	MPI	GitHub
Open	Unconfirmed New Reopened	EMI Open	Open	Open	New	New
Accepted	Assigned	Accepted	Accepted	Accepted	In progress	Accepted	not defined
Fixed	Resolved/Fixed	EMI Resolved	Integration Candidate	Fixed	Resolved	Fixed
Tested/Not Tested	Verified/Fixed	EMI Certified/Not Certified	Fix Certified/Fix not Certified	Separate testing tracker	Tested/Not Tested	Tested/Not Tested	not defined
Closed	Closed (after released to production)	EMI Closed	Closed (after released to production)	Closed (after fix commited to VCS)	Closed	Closed (after fixed. Then ticket reopened and closed again with tested/not tested)
Resolution state	Resolved/Fixed Resolved/Invalid Resolved/Wontfix Resolved/Duplicate Resolved/Worksforme	Rejected	Duplicate Won't fix Invalid Unreproducible Obsolete	Fixed Invalid Rejected	Rejected Closed (Positive State)	Fixed Tested/Not Tested Invalid Won't Fix Duplicate	not defined

For the states that are not present in the trackers by default, middlewares must provide the missing information in the XML file needed by SA2.3 to calculate metrics.

3. SA2.3 XML mapping

In order to calculate metrics, SA2.3 needs to gather information from the different trackers. This is done exporting the tracker information to an XML file that follows a schema defined by SA2.3. The schema represents the required RfC fields defined in the Change Management Policy.

The following table presents the mapping of the different XML files with the existing schema defined by SA2.3 in order to properly calculate metrics:

RfC field	XML Element	ARC	dCache	gLite	UNICORE	StoRM	MPI	GitHub
Unique Identifier/URL	UID	URL	URL	URL	URL		URL
Associated GGUS tickets	GGUS ticket				Not defined			not defined
Affected Product	Component	Product names do not follow DNA1.3.2			Product names do not follow DNA1.3.2
Affected EMI Major release	AffectedEMIMajorRelease
Affected Platforms	AffectedPlatforms
Priority	Priority		But all tickets are low!
Defect vs Feature	Severity				But all are defects!
Detection Area	DetectionArea	No testing	No production or testing		No production or testing
Target EMI major release	TargetEMIMajorRelease				-
Status	Status and StatusChangeTimestamps
Associated Test	Associated Test							not defined

To be followed up:

• UNICORE reports that it will be difficult for them to differentiate between Target EMI major release and Affected EMI Major release. If this is really needed we have to understand with them how they can provide this information.
• UNICORE has problems to include the GGUS ticket information. It's suggested to mark as production those RfCs that come from a GGUS ticket since otherwise it doesn't seem feasible to provide this now.

4. Fields under discussion

None

The following field has been renamed to Associated Test to make it valid for regression and functionality tests. It was already discussed and approved by all PTs. It has been added to the Change Management Policy as of v3.3:

Proposed RfC Field	Definition	ARC Bugzilla	dCache RT	gLite Savannah	UNICORE SourceForge	StoRM Redmine
Regression Test	Field indicating whether the RfC has an associated Regression Test	OK to add in XML file	OK to add in tracker	OK to add in tracker	OK to add in XML file	OK to add in tracker

Comment from dCache: Regression tests will be there for all major features that EMI releases will have starting from EMI 2. For EMI 1 it won't be provided.

Review Information

The table below explains whether the information displayed in this twiki has been reviewed by the PTs, when it was the last time it was reviewed and which changes have been applied.

• General review on 04.10.2011. Results reported in TASK:22734.