Release Management Policy

1. Introduction

This document describes the EMI policy to be followed when managing EMI releases.

2. Release Process

2.1. Roles and responsibilities

• EMT: The EMT is the Engineering Management Team and is responsible for managing the release process and the software changes. This is lead by the Release Manager. It is composed of:
  • Product Team leaders. The list of product teams [R1] containining the corresponding leader and the associated software products should be kept up to date. The Release Manager has to monitor this and contact the PTB in case of missing or outdated information.
  • QA representative
  • Security representative
  • Operation team representatives of major infrastructures (EGI, PRACE, etc)
  • Invited experts
• Release Manager: The Release Manager is responsible for managing the EMT.
• Technical Director: The Technical Director is responsible for defining the Technical Development Plan [R10] and deciding on specific technical issues.
• Technical Area leaders: The Technical Area leaders are responsible for writing the Technical Area work plans and coordinating the work of the different PTs within their area.
• JRA1 activity leader: The JRA1 activity leader is responsible for collecting the technical objectives of the project from the different Technical Area work plans, making sure they are aligned with the Technical Development plan and together with the Release Manager, define the release schedule.
• QC activities: quality control activities are responsible for reviewing the EMI releases making sure they comply with the policies defined by SA2.

2.2. Tasks

The following tasks are part of the release process.

2.2.1. Technical Management of Releases

2.2.1.1. Introduction

The Release Manager should coordinate the EMI releases. The following picture represents how a release is defined:

The following items are key components of a release:

• User requirements: These are high level descriptions of requirements that imply changes in the software that need to be discussed and approved first by the PTB. They are coming from the major DCIs using the EMI middleware although they can also come directly from PTs.
• Development Tasks: Development tasks are the high level technical objectives defined in the Technical Development Plan [R10] and the specific milestones defined in the Technical Area work plans (Compute Area Work Plan [R12], Data Area Work Plan [R13], Security Area Work Plan [R14] and Infrastructure Area Work Plan [R15]).
• GGUS tickets: Users should always report incidents or requests through the GGUS portal [R16]. GGUS incidents/requests will be transformed into RfCs when accepted by the PTs. In some cases, PTs may need prior management approval before they can implement the reported incidents/requests.
• RfCs: A Request for Change (RfC) describes a change in the software associated to a specific product. Check the Change Management Policy [R2] for more details.
• Release Tasks: Release Tasks are collections of RfCs to be released. Check the Change Management Policy [R2] for more details.

2.2.1.2. Release trackers

User Requirement Tracker

• It can be found in Savannah under: EMI Requirements Tracker [R3].
• It tracks user requirements coming from the DCIs using the EMI software. This requirements are communicated via the management bodies of EMI and the DCIs. User requirements can also arrive directly from the PTs.
• User Requirement Tasks must be related to the corresponding Development Tasks.
• The EMI PTB is responsible for making sure that a task is created in Savannah for each user requirement.
• The EMI PTB is responsible for tracking the open tasks and closing them when the user requirements have been implemented.

Development Tracker

• It can be found in Savannah under: EMI Development Tracker [R4]. The tracker is world readable but only the Technical Director, the JRA1 activity leader and the Technical Area leaders have write access.
• It tracks both the high level technical objectives defined in the DNA1.3.2 - Technical Development Plan [R10] and the corresponding technical objectives broke down to product team level as defined in the Technical Area Work Plans. Development tasks are also motivated by user requirements expressed by the DCIs. All development taking place in EMI should correspond to a development task.
• The Technical Director and the JRA1 activity leader are responsible for creating the tasks in Savannah for each development objective with the help of the Technical Area leaders. The development tasks are considered the same as RfCs and attached to the relevant release tasks.
• The JRA1 activity leader is responsible for tracking the open development tasks and closing them when the objective has been addressed.

Release Tracker

• It can be found in Savannah under: EMI ReleasesTracker [R5].
• It tracks new product versions. The set of open release tasks conforms the release schedule.
• The Release Manager is responsible for making sure that a release task is created in Savannah for each new product version, where the corresponding RfCs and Development tasks of that product will be attached taking into account their priority. This has to be done in coordination with the JRA1 activity leader and the different PTs, making sure all the technical objectives and user requirements are addressed within the expected deadlines. Release Tasks are described in detail in the Change Management Policy [R2].
• The Release Manager is responsible for monitoring the progress of the release tasks, making sure with the help of QC, that they meet the Production Release Criteria [R6] and the release schedule.

RfC Tracker

• It tracks RfCs for the different middleware products. RfCs are described in detail in the Change Management Policy [R2].
• PTs are responsible for creating entries in the RfC tracking tool. In this case, RfCs can be motivated by those GGUS tickets describing a problem or after an internal decision within the PT. GGUS tickets requesting something that needs discussion and negotiation by the management will be discussed in the appropriate management meetings and considered as user requirements tracked in the User Requirements Tracker.
• Each RfC should have a priority defined. The assigment of priorities is described in the Change Management Policy [R2].

EMT Tracker

• It can be found in Savannah under EMT tracker [R7].
• It tracks EMT incidents, these are blocking issues that prevent PTs from meeting the defined release schedule (i.e. interdependency problems, ETICS issues...). It also tracks Documentation issues related to missing or outdated documentation.
• The Release Manager is responsible for making sure that EMT tasks are opened when blocking issues are reported. The Documentation Team is responsible for opening tasks related to documentation . For more information on documentation issues, please check the Documentation Review Process [R11].
• The Release Manager is responsible for monitoring the progress of the tasks every week at the EMT meetings.
• Each EMT incident should be attached to the set of affected release tasks.

2.2.2. Continuous integration

The Release Manager is responsible for monitoring the continuous integration of the software products that are part of an EMI release. This will be achieved by monitoring the results of the nightly builds. In case of errors, the Release Manager should notify the relevant product teams and follow up that the issues are fixed.

2.2.3. Release Notes and Repository creation

The Release Manager is responsible for creating the middleware release notes and the EMI repository.

The middleware release notes must contain information about:

• the supported platforms
• installation methods (for clean and upgrade installations)
• list of links to the affected packages
• specific product release notes
• list of RfCs
• support information

Packages in the EMI repository must be signed as specified in the EMI signing [R8] Twiki.

2.2.4. EMT coordination meetings

The Release Manager is also responsible for organising EMT coordination meetings where outstanding issues are discussed with the relevant parties.

The Release Manager is responsible for preparing an agenda that should be sent to the EMT members. In the agenda, the following items should be specified:

• Date, time and any other details (meeting room, phone conference details) of the meeting.
• PTs that should attend the meeting. Although it's highly recommended, not all the PTs need to attend the EMT meeting. For this reason, in case the presence of a specific PT is required, this has to be clearly stated in the agenda. If a PT is invited and can't join the meeting, he will report to the Release Manager in advance, trying to give as many details as possible.
• Time for comments about the minutes of the previous meeting.
• Report on the status of releases by the Release Manager. This report will summarise the situation about the current EMI major releases mentioning any outstanding issues and reminding important deadlines.
• Report on continuous integration by the Release Manager.
  • In case of errors, the affected ETICS configurations should be indicated. The PT responsible for those ETICS configurations should be present in the meeting. Specific actions to fix the errors will be discussed and defined during the meeting. If necessary, a new EMT incident will be opened in the EMT tracker.
• Report about the progress of release tasks not meeting the release schedule. This will be done by the relevant PT. The PT should explain the reason why the release task is delayed, clearly specifying if there are problems with other products out of the scope of the PT itself. In this case, the Release Manager should coordinate with other PTs to solve the problem opening an EMT incident in the EMT tracker, if necessary. A new deadline for the release task may need to be defined.
• Report about problems blocking a release task. This will be done by the PTs involved in the problem. They should report about the progress being made. Specific actions to ensure the progress towards a solution have to defined. All the decisions taken should be reported in the EMT tracker.
• Report about new RfCs with Priority High=. The Release Manager will inform the EMT about unplanned RfC that have priority =High, which means the RfC needs to be included in the next release of the affected product. The associated PT should acknowledge this fact and agree with the priority.
• QA announcements. An SA2 representative should always be present at the EMT meetings to answer any question related to policies, tools or testbeds. In case of changes in any of these areas, the SA2 representative should report about it at the EMT. If specific actions are needed in any of these areas, they will be also defined at the EMT meeting.
• Report about any other open actions defined in previous meetings. This may affect any of the members of the EMT. In that case, the Release Manager has to make sure the right people are invited to attend the meeting by specifying it in the agenda.
• Any other business.

The Release Manager or any other member of the EMT appointed by him should take care of taking the minutes of the meeting. The minutes should include:

• Date of the meeting.
• The names of the people participating in the meeting.
• The names of the people who were invited to participate in the meeting and didn't attend it.
• For each relevant section in the agenda:
  • Summary of the discussions relevant to the item in the agenda.
  • List of defined actions. Stating WHAT, WHO and WHEN.

The minutes should be sent to the EMT at least before the next EMT meeting. All PT members are expected to read the EMT minutes to be informed about the decisions that have been taken.

EMT metrics report

A metrics report prepared by SA2 is provided to the Release Manager every Friday.

The report helps the Release Manager to coordinate the EMI releases and it is used at the weekly EMT meetings.

An SA2 member reviews the metrics report before sending it to the Release Manager. The following information should be present:

• Succesful builds including a link to the mapping between PTs and ETICS components.
• Untouched immediate/High priority RfCs including a link to the RfCs. This metric helps to understand whether RfCs have been opened for more than 2 weeks and no action has been performed by the PTs.
• Accepted immediate/High priority RfCs not assigned to any release yet, including a link to the RfCs. This metric helps to understand whether RfCs have been accepted without prior EMT approval. Approved RfCs need to be either attached to a release task or have a Target EMI major release defined.

GGUS report

A GGUS report prepared by SA1 is provided to the Release Manager every week.

The report helps the Release Manager to have an overview of reported incidents affecting EMI Support Units (SUs).

The following information should be present:

• Link to the GGUS dashboard containing EMI tickets [R9].
• Total number of EMI SUs GGUS tickets.
• Statistics per states.
• Statistics per priority (top priority and very urgent), including the links to the tickets.

2.3. PTs not participating at the EMT meetings

In order to guarantee that the release schedule is met and that RfCs are processed within the expected time frames, the following procedure should be applied in case PTs are not participating in the EMT meetings.

• At the end of any EMT meeting, the Release Manager should check the minutes and contact the PTs who were requested to attend the meeting and were not present. This doesn't include those PTs who have warned in advance about their unavailablity AND have sent their reports to the Release Manager. The Release Manager will also contact the relevant area leader.
• The PT should then contact the Release Manager as soon as possible and help to make progress on the relevant issues.
• If the PT hasn't contacted the Release Manager before the next EMT meeting takes place, the Release Manager will state this in the agenda as an open issue, he will explain the situation during the meeting and the minutes will be sent to the PEB.
• The PEB is then responsible for taking the necessary measures.

3. Release Manager contact

• release-manager@eu-emiNOSPAMPLEASE.eu

4. Contacts

5. Table of References

Reference	URL
R1	EMI Product Team List https://twiki.cern.ch/twiki/bin/view/EMI/EmiProductTeams
R2	EMI Change Management Policy https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangePolicy
R3	EMI Requirements Tracker https://savannah.cern.ch/task/?group=emi-req
R4	EMI Development Tracker https://savannah.cern.ch/task/?group=emi-dev
R5	EMI Release Tracker https://savannah.cern.ch/task/?group=emi-releases
R6	EMI Production Release Criteria https://twiki.cern.ch/twiki/bin/view/EMI/ProductionReleaseCriteria
R7	EMI EMT Tracker https://savannah.cern.ch/projects/emi-emt/
R8	EMI Signing Process https://twiki.cern.ch/twiki/bin/view/EMI/EMISigning
R9	GGUS EMI Dashboard https://ggus.eu/tech/dashboard.php
R10	DNA1.3.2 - Technical Development Plan https://twiki.cern.ch/twiki/pub/EMI/DeliverableDNA132
R11	EMI Documentation Review Process https://twiki.cern.ch/twiki/bin/view/EMI/EMIDocReviewProcess
R12	DJRA1.1.2 - Compute Area Work Plan https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA112
R13	DJRA1.2.2 - Data Area Work Plan https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA122
R14	DJRA1.3.2 - Security Area Work Plan https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA132
R15	DJRA1.4.2 - Infrastructure Area Work Plan https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA142
R16	GGUS Portal https://ggus.org/

6. Logbook

Details Hide Details