Difference between revisions of "EGI Software Component Delivery"

From EGIWiki
Jump to: navigation, search
(Created page with " <br> DRAFT<br> = EGI Software Component Delivery = == <span style="background: #ffff00">Component r<span id="1423728260410S" style="display: none;"> </span>oadmap and...")
 
Line 1: Line 1:
+
<br> <br> DRAFT<br>  
 
 
<br> DRAFT<br>  
 
  
 
= EGI Software Component Delivery  =
 
= EGI Software Component Delivery  =
  
== <span style="background: #ffff00">Component r<span id="1423728260410S" style="display: none;">&nbsp;</span>oadmap and release plan</span>  ==
+
== <span style="background: #ffff00">Component r<span style="display: none;" id="1423728260410S">&nbsp;</span>oadmap and release plan</span>  ==
  
 
<span style="background: #ffff00">The Provider will publish a roadmap
 
<span style="background: #ffff00">The Provider will publish a roadmap
Line 14: Line 12:
  
 
*<span style="background: #ffff00">All planned major component
 
*<span style="background: #ffff00">All planned major component
releases</span>
+
</span>releases
  
 
*<span style="background: #ffff00">All planned minor component
 
*<span style="background: #ffff00">All planned minor component
releases</span>
+
</span>releases
  
 
*<span style="background: #ffff00">Planned new features in the
 
*<span style="background: #ffff00">Planned new features in the
component</span>
+
</span>component
  
 
*<span style="background: #ffff00">Incompatibilities between releases
 
*<span style="background: #ffff00">Incompatibilities between releases
</span>
+
</span>
 +
 
 +
 
  
 
<br>  
 
<br>  
Line 52: Line 52:
 
inform EGI whenever the release plan is changed.</span>  
 
inform EGI whenever the release plan is changed.</span>  
  
<br>
+
<br>  
  
 
=== R<span style="background: #ffff00">elease delivery and format</span>  ===
 
=== R<span style="background: #ffff00">elease delivery and format</span>  ===
Line 63: Line 63:
 
</span>  
 
</span>  
  
<br>
+
<br>  
  
 
== Quality Assurance  ==
 
== Quality Assurance  ==
Line 72: Line 72:
 
designated successors.</span>  
 
designated successors.</span>  
  
<br>
+
<br>  
  
 
=== <span style="background: #ffff00">Acceptance Criteria</span>  ===
 
=== <span style="background: #ffff00">Acceptance Criteria</span>  ===
Line 88: Line 88:
 
considered to be part of, the UMD. </span>  
 
considered to be part of, the UMD. </span>  
  
<br>
+
<br>  
  
 
=== T<span style="background: #ffff00">est plans</span>  ===
 
=== T<span style="background: #ffff00">est plans</span>  ===
Line 101: Line 101:
  
 
*<span style="background: #ffff00">All tests available, or at least
 
*<span style="background: #ffff00">All tests available, or at least
an executive overview of all tests available</span>
+
</span>
 +
 
 +
an executive overview of all tests available  
  
 
*<span style="background: #ffff00">The complete, detailed list of all
 
*<span style="background: #ffff00">The complete, detailed list of all
tests executed for the given release of the component in question</span>
+
</span>
 +
 
 +
tests executed for the given release of the component in question  
  
 
*<span style="background: #ffff00">The complete, detailed result of
 
*<span style="background: #ffff00">The complete, detailed result of
each executed test</span>
+
</span>
 +
 
 +
each executed test
  
 
*<span style="background: #ffff00">References to and descriptions of
 
*<span style="background: #ffff00">References to and descriptions of
any required 3</span><sup><span style="background: #ffff00">rd</span></sup><span style="background: #ffff00">
+
</span>
party software necessary to execute the test plans.</span><br>
+
 
 +
any required 3<sup><span style="background: #ffff00">rd</span></sup><span style="background: #ffff00">
 +
party software necessary to execute the test plans.</span><br>  
  
<br>
+
<br>  
  
 
<span style="background: #ffff00">The test plan as described above
 
<span style="background: #ffff00">The test plan as described above
Line 120: Line 128:
  
 
*<span style="background: #ffff00">Major release: At least 20 working
 
*<span style="background: #ffff00">Major release: At least 20 working
days </span>
+
</span>
 +
 
 +
days
  
 
*<span style="background: #ffff00">Minor release: At least 15 working
 
*<span style="background: #ffff00">Minor release: At least 15 working
days</span>
+
</span>
 +
 
 +
days
  
 
*<span style="background: #ffff00">Revision release: At least 10
 
*<span style="background: #ffff00">Revision release: At least 10
working days </span>
+
</span>
 +
 
 +
working days
  
 
*<span style="background: #ffff00">Emergency release: N/A</span>
 
*<span style="background: #ffff00">Emergency release: N/A</span>
Line 139: Line 153:
  
 
*<span style="background: #ffff00">Rerun the complete test plan for
 
*<span style="background: #ffff00">Rerun the complete test plan for
major releases</span>
+
</span>
 +
 
 +
major releases
  
 
*<span style="background: #ffff00">Run a subset of the tests of the
 
*<span style="background: #ffff00">Run a subset of the tests of the
test plan (chosen by EGI) for minor releases</span>
+
</span>
 +
 
 +
test plan (chosen by EGI) for minor releases  
  
 
<br>  
 
<br>  
Line 156: Line 174:
 
the Provider.</span>  
 
the Provider.</span>  
  
<br>
+
<br>  
  
 
=== I<span style="background: #ffff00">ssue management infrastructure</span>  ===
 
=== I<span style="background: #ffff00">ssue management infrastructure</span>  ===
Line 167: Line 185:
 
performance is implemented through this SU. </span>  
 
performance is implemented through this SU. </span>  
  
<br>
+
<br>  
  
 
=== I<span style="background: #ffff00">ssue Resolution</span>  ===
 
=== I<span style="background: #ffff00">ssue Resolution</span>  ===
Line 191: Line 209:
 
constraint of the agreed ETA:</span>  
 
constraint of the agreed ETA:</span>  
  
#<span style="background: #ffff00">Top priority</span><br>
+
#<span style="background: #ffff00">Top priority</span><br>  
#<span style="background: #ffff00">Very urgent</span><br>
+
#<span style="background: #ffff00">Very urgent</span><br>  
 
#<span style="background: #ffff00">Urgent</span>  
 
#<span style="background: #ffff00">Urgent</span>  
 
#<span style="background: #ffff00">Less Urgent</span><br>
 
#<span style="background: #ffff00">Less Urgent</span><br>
Line 213: Line 231:
 
soon as possible, or at least within 2 working days.</span>  
 
soon as possible, or at least within 2 working days.</span>  
  
<br>
+
<br>  
  
 
=== <span style="background: #ffff00">Vulnerability Resolution</span>  ===
 
=== <span style="background: #ffff00">Vulnerability Resolution</span>  ===
Line 240: Line 258:
 
following order:</span>  
 
following order:</span>  
  
#<span style="display: none;" id="1423728369743S">&nbsp;</span><span style="background: #ffff00">Critical</span>  
+
#<span id="1423728369743S" style="display: none;">&nbsp;</span><span style="background: #ffff00">Critical</span>  
 
#<span style="background: #ffff00">High</span>  
 
#<span style="background: #ffff00">High</span>  
 
#<span style="background: #ffff00">Moderate</span>  
 
#<span style="background: #ffff00">Moderate</span>  
#<span style="background: #ffff00">Low<span style="display: none;" id="1423728369994E">&nbsp;</span></span><br>
+
#<span style="background: #ffff00">Low<span id="1423728369994E" style="display: none;">&nbsp;</span></span><br>
  
 
{| width="635" cellspacing="0" cellpadding="7"
 
{| width="635" cellspacing="0" cellpadding="7"
Line 276: Line 294:
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
#<span lang="en-US">All fixes that are delivered within TD </span><span lang="en-US">''and''</span><span lang="en-US">
 
#<span lang="en-US">All fixes that are delivered within TD </span><span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted. </span>
+
</span>
 +
 
 +
have passed the SW Rollout process are counted.  
 +
 
 
#Aggregated during the reporting month.
 
#Aggregated during the reporting month.
  
Line 288: Line 309:
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
#<span lang="en-US">All fixes that are delivered </span><span lang="en-US">''after''</span><span lang="en-US">
 
#<span lang="en-US">All fixes that are delivered </span><span lang="en-US">''after''</span><span lang="en-US">
TD </span><span lang="en-US">''and''</span><span lang="en-US">
+
</span>
 +
 
 +
TD <span lang="en-US">''and''</span><span lang="en-US">
 
have passed the SW Rollout process are counted. </span>  
 
have passed the SW Rollout process are counted. </span>  
 +
 
#Aggregated during the reporting month.
 
#Aggregated during the reporting month.
  
Line 366: Line 390:
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
#<span lang="en-US">All fixes that are delivered within ETA </span><span lang="en-US">''and''</span><span lang="en-US">
 
#<span lang="en-US">All fixes that are delivered within ETA </span><span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted.</span>
+
</span>
 +
 
 +
have passed the SW Rollout process are counted.  
 +
 
 
#Aggregated during the reporting month.
 
#Aggregated during the reporting month.
  
Line 378: Line 405:
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
#<span lang="en-US">All fixes that are delivered within ETA + 1
 
#<span lang="en-US">All fixes that are delivered within ETA + 1
calendar week </span><span lang="en-US">''and''</span><span lang="en-US">
+
</span>
 +
 
 +
calendar week <span lang="en-US">''and''</span><span lang="en-US">
 
have passed the SW Rollout process are counted.</span>  
 
have passed the SW Rollout process are counted.</span>  
 +
 
#Aggregated during the reporting month.
 
#Aggregated during the reporting month.
  
Line 391: Line 421:
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
#<span lang="en-US">All fixes that are delivered within ETA (+ 1
 
#<span lang="en-US">All fixes that are delivered within ETA (+ 1
calendar month) </span><span lang="en-US">''and''</span><span lang="en-US">
+
</span>
 +
 
 +
calendar month) <span lang="en-US">''and''</span><span lang="en-US">
 
have passed the SW Rollout process are counted.</span>  
 
have passed the SW Rollout process are counted.</span>  
 +
 
#Aggregated during the reporting month.
 
#Aggregated during the reporting month.
  
Line 437: Line 470:
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
 
#<span lang="en-US">Every occurrence of a violation of the service
 
#<span lang="en-US">Every occurrence of a violation of the service
request response times agreed to in section Błąd: Nie znaleziono źródła odwołania
+
</span>
is counted.</span>
+
 
 +
request response times agreed to in section Błąd: Nie znaleziono źródła odwołania is counted.  
 +
 
 
#Aggregated during the reporting month.
 
#Aggregated during the reporting month.
  
Line 603: Line 638:
 
###<br><br>  
 
###<br><br>  
 
#<span style="background: #ffff00">For any vulnerability found in any
 
#<span style="background: #ffff00">For any vulnerability found in any
software component delivered by the Provider, the Provider agrees to
+
</span>
the best of their ability that no information about the vulnerability
+
 
shall be disclosed to the public without consent of the SVG.</span><span style="background: #ffff00">
+
software component delivered by the Provider, the Provider agrees to the best of their ability that no information about the vulnerability shall be disclosed to the public without consent of the SVG.<span style="background: #ffff00">
 
Other Software Vulnerability groups may be informed without prior
 
Other Software Vulnerability groups may be informed without prior
 
consent of the EGI SVG, provided they have a non-disclosure policy,
 
consent of the EGI SVG, provided they have a non-disclosure policy,
Line 612: Line 647:
 
the UMD prior to public or other widespread disclosure of the
 
the UMD prior to public or other widespread disclosure of the
 
vulnerability.</span>  
 
vulnerability.</span>  
#<br>
+
 
 +
#<br>  
 
#Metrics  
 
#Metrics  
 
#Each metric is a positive integer number, including 0 (zero). “Secondary” metrics (i.e. metrics with an ID counter larger than 1) are constrained in that they cannot reach numbers greater than the pertinent “main” metrics (i.e. M.*.1).  
 
#Each metric is a positive integer number, including 0 (zero). “Secondary” metrics (i.e. metrics with an ID counter larger than 1) are constrained in that they cannot reach numbers greater than the pertinent “main” metrics (i.e. M.*.1).  
 
#All metrics are collected on a monthly basis, starting on the first calendar day of the month, and ending on the respective last day of the month.  
 
#All metrics are collected on a monthly basis, starting on the first calendar day of the month, and ending on the respective last day of the month.  
 
#<br><br>  
 
#<br><br>  
#<br>
+
#<br>  
 
#Objectives  
 
#Objectives  
 
#Objectives are decimal numbers with a precision of 2 decimals rounded. In case of any main metric, at the point of collection, has the value 0 (zero) the related objective shall have the value “0.00%”  
 
#Objectives are decimal numbers with a precision of 2 decimals rounded. In case of any main metric, at the point of collection, has the value 0 (zero) the related objective shall have the value “0.00%”  
Line 625: Line 661:
 
#Due to the expected small number of software Products contributed by IGE a sensible relation-based metering of objective targets is not possible. Instead, IGE and EGI agree that objectives undergo quarterly review collecting input across EGI management bodies and activities (SVG, RAT, DMSU, TCB, etc.) and a formal overall ratification that collected metrics are within reason.  
 
#Due to the expected small number of software Products contributed by IGE a sensible relation-based metering of objective targets is not possible. Instead, IGE and EGI agree that objectives undergo quarterly review collecting input across EGI management bodies and activities (SVG, RAT, DMSU, TCB, etc.) and a formal overall ratification that collected metrics are within reason.  
 
#The performance of IGE in said activities will be individually reviewed and assessed on the following scale:  
 
#The performance of IGE in said activities will be individually reviewed and assessed on the following scale:  
#<br>
+
#<br>  
 
#Performance above expectations  
 
#Performance above expectations  
#<br>
+
#<br>  
 
#Performance as expected  
 
#Performance as expected  
#<br>
+
#<br>  
 
#Performance below expectation  
 
#Performance below expectation  
 
##The review will include assessment of the past period, and expectations for the subsequent period.  
 
##The review will include assessment of the past period, and expectations for the subsequent period.  
 
#<br><br>  
 
#<br><br>  
#[[Category:Infrastructure_Oversight]]
+
#
 
#<br>
 
#<br>
  
<br>
+
<br>  
 +
 
 +
[[Category:Infrastructure_Oversight]]

Revision as of 10:10, 12 February 2015



DRAFT

EGI Software Component Delivery

Component roadmap and release plan

The Provider will publish a roadmap for each component it wishes to release to EGI. The roadmap may be consolidated into one document with the roadmaps for other components if the Provider releases more than one component to EGI. The roadmap must contain:

  • All planned major component

releases

  • All planned minor component

releases

  • Planned new features in the

component

  • Incompatibilities between releases



The Provider will update the roadmap(s) every half year (six calendar months) at least one calendar month before EGI publishes the UMD Roadmap on its scheduled dates [Błąd: Nie znaleziono źródła odwołania].


The Provider will make available a release plan for each component published in the Provider’s software repository. The Provider may consolidate release plans of more than one component into a consolidated series of one or more documents, for a better overview. The release plan must provide the planned release dates for all maintained software components for at least one year into the future and must include the release dates for

  • All major releases
  • All minor releases


The Technology Provider agrees to inform EGI whenever the release plan is changed.


Release delivery and format

The Provider agrees to deliver releases on a regular basis and provides electronic access to the release contents as described in [Błąd: Nie znaleziono źródła odwołania]. The new release must be delivered by creating a tracker artefact in GGUS containing XML based technical description of the release [Błąd: Nie znaleziono źródła odwołania].


Quality Assurance

The Provider understands and accepts the Software Provisioning Process as described in EGI-InSPIRE Milestone MS503 [Błąd: Nie znaleziono źródła odwołania] and its designated successors.


Acceptance Criteria

The evolution of acceptance criteria is a normal process considering the settings within which EGI and the Provider operate.


Through active participation in the TCB the Provider advises EGI on the effort required to implement any changes to generic or specific acceptance criteria that may affect any of the maintained software components that are part of, or considered to be part of, the UMD.


Test plans

The Provider agrees to formally provide or make available to EGI the complete test plans and results of continuous testing and integration of each maintained software component.

The test plan for a given release of one particular component must include:

  • All tests available, or at least

an executive overview of all tests available

  • The complete, detailed list of all

tests executed for the given release of the component in question

  • The complete, detailed result of

each executed test

  • References to and descriptions of

any required 3rd party software necessary to execute the test plans.


The test plan as described above must be made available to EGI prior to the planned release date for review:

  • Major release: At least 20 working

days

  • Minor release: At least 15 working

days

  • Revision release: At least 10

working days

  • Emergency release: N/A


Prior to entering EGI’s Software Provisioning Process [Błąd: Nie znaleziono źródła odwołania] and upon request of EGI’s appropriate management unit, the Provider, in collaboration with EGI, agrees to the best of their ability to:

  • Rerun the complete test plan for

major releases

  • Run a subset of the tests of the

test plan (chosen by EGI) for minor releases


Issue management

The Provider has appointed personnel for technical issues concerning the maintained software components. Those technical contacts must be fully authorised to act as the Provider’s representative in collaboration with EGI DMSU [Błąd: Nie znaleziono źródła odwołania] regarding the triaging, assessment and resolution of any technical issues concerning the software components developed and maintained by the Provider.


Issue management infrastructure

EGI uses GGUS for 2nd level (DMSU) support. For 3rd-level support, EGI provides the Technology Provider with a provider-specific Support Unit (SU) in GGUS as 3rd level support interface. Monitoring and reporting of provider performance is implemented through this SU.


Issue Resolution

The Provider constructively works in close collaboration with EGI DMSU on jointly investigating issues raised against software components maintained by the Provider. The investigation includes triaging the issue or incident, the problem and any known impacts. The details of the process of collaboration with the DMSU are outlined in [Błąd: Nie znaleziono źródła odwołania].


In case the triage resolves to the production of a new release of the affected software component DMSU and the service provider jointly agree on an Estimated Time of Availability (ETA) of the necessary new release of that software component.

The Provider agrees to prioritise the effort to resolve and fix reported issues according to their priority as set in GGUS, in the following order, while respecting the constraint of the agreed ETA:

  1. Top priority
  2. Very urgent
  3. Urgent
  4. Less Urgent

Vulnerability management

The Provider has appointed personnel for vulnerability issues concerning the maintained software components. Those security contacts must be fully authorised to act as the Provider’s representative in collaboration with EGI SVG [Błąd: Nie znaleziono źródła odwołania] and related boards regarding the triaging, assessment and resolution of any vulnerability issues concerning the software components developed and maintained by the Provider.



Any appointed security contact for any delivered software component must respond to any request by the EGI SVG and associated groups (e.g. RAT). The response must be as soon as possible, or at least within 2 working days.


Vulnerability Resolution

The Provider agrees that any software vulnerability found in their delivered software while running on EGI production infrastructure must be handled using the SVG process [Błąd: Nie znaleziono źródła odwołania].



The Provider agrees that any software vulnerability in their delivered software found otherwise must be reported to the EGI SVG. If the vulnerability is reported before a fix is available, the vulnerability must be treated and resolved as if found on EGI production infrastructure, i.e. it must be handled using the SVG process. If the vulnerability is reported after a fix is available, the Provider coordinates with SVG to make available the new release including an appropriate advisory for SW release on EGI production infrastructure.



The Provider agrees to prioritise vulnerability resolution according to their risk assessment, in the following order:

  1. Critical
  2. High
  3. Moderate
  4. Low
  1. Metric ID
  1. Metric
  1. Explanation
  1. M.SVG.1
  1. Number of confirmed new vulnerabilities per month
  1. The total number of vulnerabilities discovered in all maintained software components, whether within EGI activities or outside, are collected and published.
  2. Aggregated during the reporting month.
  1. M.SVG.2
  1. Number of fixes delivered within TD
  1. All fixes that are delivered within TD and

have passed the SW Rollout process are counted.

  1. Aggregated during the reporting month.
  1. M.SVG.3
  1. Number of fixes delivered after TD
  1. All fixes that are delivered after

TD and have passed the SW Rollout process are counted.

  1. Aggregated during the reporting month.
  1. M.SVG.4
  1. Number of confirmed open vulnerabilities which have exceeded the TD
  1. Number of confirmed vulnerabilities, which have not been fixed and have passed the TD at the time of calculating.
  2. Current value taken at the end of the reporting month on the last working at 18:00 CE(S)T.
  1. M.SVG.5
  1. Total number of open vulnerabilities
  1. Current value taken at the end of the reporting month on the last working day at 18:00 CE(S)T.
  1. M.SVG.6
  1. Number of requests to the Provider
  1. The total number of requests for information and/or participation in investigation of issues to IGE concerning vulnerabilities.
  2. Aggregated during the reporting month.
  1. M.SVG.7
  1. Number of contact responses below 2 day target
  1. Each request made by the SVG or associated boards that were not reacted upon within 2 working days are counted.
  2. Aggregated during the reporting month.
  1. M.DMSU.1
  1. Number of issues assigned to the Provider
  1. The total numbers of confirmed issues that require the Provider’s effort to produce a new release are counted.
  2. Aggregated during the reporting month.
  1. M.DMSU.2
  1. Number of issues with revised ETA
  1. The total number of issues for which the Provider changed the ETA are counted.
  2. Aggregated during the reporting month.
  1. M.DMSU.3
  1. Number of fixes delivered within ETA
  1. All fixes that are delivered within ETA and

have passed the SW Rollout process are counted.

  1. Aggregated during the reporting month.
  1. M.DMSU.4
  1. Number of fixes delivered within ETA + 1 week
  1. All fixes that are delivered within ETA + 1

calendar week and have passed the SW Rollout process are counted.

  1. Aggregated during the reporting month.
  1. M.DMSU.5
  1. Number of fixes delivered within ETA + 1 month
  1. All fixes that are delivered within ETA (+ 1

calendar month) and have passed the SW Rollout process are counted.

  1. Aggregated during the reporting month.
  1. M.REPO.1
  1. Number of releases delivered to EGI
  1. The total number of releases made available to EGI through the SW Rollout process is counted.
  2. Aggregated during the reporting month.
  1. M.REPO.2
  1. Number of releases that passed the quality criteria verification.
  1. All releases that passed the quality criteria verification process are counted. Release submissions that result in changes of quality criteria applicable to the pertinent component are not counted in this metric.
  2. Aggregated during the reporting month.
  1. M.REPO.3
  1. Number of releases that passed StageRollout verification
  1. All releases that passed the StageRollout phase of the SW rollout process hence are accepted for production use, are counted.
  2. Aggregated during the reporting month.
  1. M.MISC.1
  1. Number of violations of service request response times
  1. Every occurrence of a violation of the service

request response times agreed to in section Błąd: Nie znaleziono źródła odwołania is counted.

  1. Aggregated during the reporting month.
  1. M.MISC.2
  1. Number of releases that failed any mandatory Generic Documentation Quality Criterion
  1. Documentation quality is a critical software quality criterion, but not part of the decision to accept or reject software based on technical failures.
  2. Aggregated during the reporting month.
  1. Objective ID
  1. Objective
  1. Calculation
  1. Target
  1. O.SVG.1
  1. Proportion of issues fixed within TD
  1. 100 * M.SVG.2 /
  2. (M.SVG.2 + M.SVG.3 + M.SVG.4)
  1. n/a
  1. O.SVG.2
  1. Proportion of open issues beyond TD
  1. M.SVG.4 / M.SVG.5 * 100
  1. n/a
  1. O.SVG.3
  1. Responsiveness of security contacts to vulnerability issues
  1. (M.SVG.7 / M.SVG.6) * 100
  1. n/a
  1. O.DMSU.1
  1. Success rate of timely delivery within ETA
  1. (M.DMSU.3 / M.DMSU.1) * 100
  1. n/a
  1. O.DMSU.2
  1. Success rate of timely delivery within ETA + 1 week
  1. (M.DMSU.4 / M.DMSU.1) * 100
  1. n/a
  1. O.DMSU.3
  1. Success rate of timely delivery within ETA + 1 month
  1. (M.DMSU.5 / M.DMSU.1) * 100
  1. n/a
  1. O.REPO.1
  1. Formal quality of component releases
  1. (M.REPO.2 / M.REPO.1) * 100
  1. n/a
  1. O.REPO.2
  1. Functional quality of component releases
  1. (M.REPO.3 / M.REPO.1) * 100
  1. n/a
  1. O.MISC.1
  1. Service response time violation
  1. M.MISC.1
  1. 0
  1. O.MISC.2
  1. Documentation quality failure
  1. M.MISC.2
  1. 0


  1. For any vulnerability found in any

software component delivered by the Provider, the Provider agrees to the best of their ability that no information about the vulnerability shall be disclosed to the public without consent of the SVG. Other Software Vulnerability groups may be informed without prior consent of the EGI SVG, provided they have a non-disclosure policy, which is compatible with that of the EGI SVG. Also, IGE and any other vulnerability groups informed must ensure that a fix is available in the UMD prior to public or other widespread disclosure of the vulnerability.


  1. Metrics
  2. Each metric is a positive integer number, including 0 (zero). “Secondary” metrics (i.e. metrics with an ID counter larger than 1) are constrained in that they cannot reach numbers greater than the pertinent “main” metrics (i.e. M.*.1).
  3. All metrics are collected on a monthly basis, starting on the first calendar day of the month, and ending on the respective last day of the month.



  4. Objectives
  5. Objectives are decimal numbers with a precision of 2 decimals rounded. In case of any main metric, at the point of collection, has the value 0 (zero) the related objective shall have the value “0.00%”
  6. Objectives are calculated using monthly metering of the metrics defined in section .




  7. Due to the expected small number of software Products contributed by IGE a sensible relation-based metering of objective targets is not possible. Instead, IGE and EGI agree that objectives undergo quarterly review collecting input across EGI management bodies and activities (SVG, RAT, DMSU, TCB, etc.) and a formal overall ratification that collected metrics are within reason.
  8. The performance of IGE in said activities will be individually reviewed and assessed on the following scale:

  9. Performance above expectations

  10. Performance as expected

  11. Performance below expectation
    1. The review will include assessment of the past period, and expectations for the subsequent period.