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. DONE DONE DONE DONE DONE DONE ALERT! awaiting values
Associated GGUS tickets If applicable, one or more URLs pointing to GGUS tickets that have caused the opening of this RfC DONE URL DONE GGUS_ID DONE GGUS reference URL ALERT! GGUS URL added in the Details field as free text. DONE DONE ALERT! awaiting values
Affected Product EMI Product List as specified in DNA1.3.2 DONE Product DONE Product ALERT! Category field exists but not sure it matches DNA1.3.2 ALERT! Category field exists but doesn't match DNA1.3.2 DONE Affected Product DONE Component ALERT! awaiting values
Affected EMI Major release EMI major release affected by the RfC DONE It can be mapped to an ARC release since there's 1:1 correspondence to EMI releases DONE EMI DONE Baseline Release ALERT! DONE DONE ALERT! awaiting values
Affected Platforms Whether the RfC is platform-specific and, if so, which are the affected platforms ALERT! Platform field exists but no multiple values although it can be generic like Linux ALERT! Since this is a Java project all platforms are supported ALERT! Architecture and OS fields exists but only one value can be specified ALERT! ALERT! Affected Platforms field exists but only one value can be specified DONE ALERT! awaiting values
Priority Immediate, High, Medium or Low DONE 1 (Immediate) 2 (High) 3 (Medium) 4 5 (Low) DONE Priority numerical field DONE Immediate, High, Medium, Low DONE 1 2 (Low) 3 4 5 (Medium) 6 7 8 (High) 9 (immediate) DONE Immediate, High, Normal, Low DONE Low, Medium, High, Immediate ALERT! awaiting values
Defect vs Feature Whether the RfC is to fix a defect or to introduce a new feature. DONE One severity level is feature request DONE Two different Queues, one for defect and one for feature. DONE Severity field exist but not sure PTs use it properly to differentiate defect and features. DONE Defects are in the Bug tracker, New features are in the Enhancements and Improvements and Feature Requests tracker DONE Bug vs Feature DONE Defect vs Feature ALERT! awaiting values
Detection Area The context in which the version of the component affected by the change is available. Possible values are production, testing and development DONE Implied by release version. Development has a special release tag CVS, and Testing are release candidate versions. Everything else is Production ALERT! One possible value only: Development DONE Bug Detection Area ALERT! DONE DONE ALERT! awaiting values
Target EMI major release The target EMI major release where the RfC will be available. DONE ARC release field it can be mapped to EMI release 1:1 DONE field can be mapped to EMI release 1:1 DONE Release ALERT! DONE DONE ALERT! awaiting values

ALERT! 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 DONE Unconfirmed
New
Reopened
DONE EMI Open DONE Open DONE Open DONE New DONE New ALERT! avaiting values
Accepted DONE Assigned DONE Accepted DONE Accepted DONE Accepted DONE In progress DONE Accepted ALERT! avaiting values
Fixed DONE Resolved/Fixed DONE EMI Resolved DONE Integration Candidate DONE Fixed DONE Resolved DONE Fixed ALERT! avaiting values
Tested/Not Tested DONE Verified/Fixed DONE EMI Certified/Not Certified DONE Fix Certified/Fix not Certified ALERT! DONE Tested/Not Tested DONE Tested/Not Tested ALERT! avaiting values
Closed DONE Closed
(after released to production)
DONE EMI Closed DONE Closed
(after released to production)
ALERT! Closed
(after fix commited to VCS)
DONE Closed DONE Closed (after fixed. Then ticket reopened and closed again with tested/not tested) ALERT! avaiting values
Resolution state DONE Resolved/Fixed
Resolved/Invalid
Resolved/Wontfix
Resolved/Duplicate
Resolved/Worksforme
DONE Rejected DONE Duplicate
Won't fix
Invalid
Unreproducible
Obsolete
DONE Fixed
Invalid
Rejected
DONE Rejected
Closed (Positive State)
DONE Fixed
Tested/Not Tested
Invalid
Won't Fix
Duplicate
ALERT! avaiting values

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 DONE URL DONE URL DONE URL DONE URL NA DONE URL NA
Associated GGUS tickets GGUS ticket DONE DONE DONE ALERT! Not defined NA DONE NA
Affected Product Component ALERT! Product names do not follow DNA1.3.2 DONE DONE ALERT! Product names do not follow DNA1.3.2 NA DONE NA
Affected EMI Major release AffectedEMIMajorRelease DONE DONE DONE DONE NA DONE NA
Affected Platforms AffectedPlatforms DONE DONE DONE DONE NA DONE NA
Priority Priority DONE DONE But all tickets are low! DONE DONE NA DONE NA
Defect vs Feature Severity DONE DONE DONE DONE But all are defects! NA DONE NA
Detection Area DetectionArea DONE No testing DONE No production or testing DONE DONE No production or testing NA DONE NA
Target EMI major release TargetEMIMajorRelease DONE DONE DONE - NA DONE NA
Status Status and StatusChangeTimestamps DONE DONE DONE DONE NA DONE NA
Associated Test Associated Test NA NA NA DONE NA DONE NA

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 DONE OK to add in XML file DONE OK to add in tracker DONE OK to add in tracker DONE OK to add in XML file DONE 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.

Tracker Reviewed by Date Comments from reviewer Comments from SA2
ARC Oxana Smirnova 15.06.2011 Clarified the existence of some fields or how they can be known otherwise through other means. 10.06.2011: Table created
15.06.2011: Added comments from Oaxanna.
18.08.2011: Reviewed XML mappings and send feedback to SA2.3.
01.09.2011: Added info in XML files for missing fields that are now included.
dCache Christian Bernardt 18.08.2011 Update unclear fields 10.06.2011: Table created
18.08.2011: Reviewed XML mappings and send feedback to SA2.3.
gLite Maria Alandes 05.07.2011 No feedback from gLite EMT mailing list. I assume developers agree with mapping. 10.06.2011: Table created
18.08.2011: Reviewed XML mappings and send feedback to SA2.3.
UNICORE Krzysztof Benedyczak 14.06.2011 Krzysztof explains why some fields are missing and how the needed info is provided by other means. 10.06.2011: Table created
14.06.2011: Added comments from Krzysztof.
18.08.2011: Reviewed XML mappings and send feedback to SA2.3.
StoRM Michele Dibenedetto 13.07.2011 Feedback on some missing fields 22.06.2011: Table created
13.07.2011: Feedback applied
18.08.2011: Reviewed XML mappings and send feedback to SA2.3.
MPI Enol Fernández 04.10.2011 Everything OK. 03.10.2011: Table created

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


This topic: EMI > WebHome > EmiProjectStructure > SA2 > EmiSa2ChangePolicy > EMITrackerMappings
Topic revision: r33 - 2012-06-15 - unknown
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback