26-27 August 2010 (The Milan Meeting)

On August 26th and 27th August the PEB had a constructive face-to-face meeting (known to many as "the Milan Meeting"), where a thorough discussion of the project status and challenges took place. The main result of the meeting has been a clarification of many issues identified during the first four months of the project and a set of important decision for the following months up the the end of the first year of EMI. In summary the main decisions and clarifications affecting the EMI project members as a whole are the following:

Administrative decisions

1. Deliverables should be submitted as close as possible to the due date. In most cases it is possible to submit a preliminary version of a deliverable and a later revision before the review. Both the preliminary version and the revised version will have to follow the deliverable submission procedure.

General technical decisions

1. A general technical roadmap for EMI must be developed by the PTB under the Technical Director leadership in the coming months. This roadmap must describe how EMI and its components will evolve over time, what are the relationships among various components and how new technologies will be considered and adopted in the EMI services
2. SA1 is responsible for the Release Plans. SA1 must therefore come up with proposals for the release schedules with as many details as possible (deadlines for design and code freeze, testing plan requirements, release dates for each major component, dependency lists, etc). The plan is presented at the PTB for any technical verification and when approved it must be enforced by all PTs leaders within each PT
3. EMI must use a common build, test and QA system as much as practically possible. Currently the system of choice is ETICS. All components to be released as part of EMI must have configurations in ETICS. Components without valid configuration in ETICS cannot be released as part of the EMI releases or with official EMI support
4. EMI components are released on two sets of platforms, mandatory and optional. Mandatory platforms must be supported by all components in a given EMI release, optional platforms can be supported by individual PTs depending on needs of technical capabilities. The mandatory platforms are decided based on requirements from the user communities, optional platforms are decided based on requirements and also on future strategical needs and opportunities
5. All components in a given EMI release must be provided at least in the standard packaging formats typical of the supported mandatory platforms, plus source and binary tarballs (on linux-like systems) or zip files (on Windows)
6. Packages not directly provided by EMI PTs (external packages) should be taken from existing standard repository (like the standard OS distributions repositories or downstream repositories like EPEL or Squeeze or other suitable alternatives) whenever possible. This will also apply to Globus packages.
7. The EMI Repository must contain always non conflicting packages and only packages that are not commonly available on standard OS repositories or other downstream repositories. All components from the same release must be in the same repository (possibly organized in terms of base, updates, security, etc, as in standard distributions)
8. JRA1 is responsible to prepare the detailed development plans for each release. The development plan are technical specifications derived from the project technical plans
9. JRA1 is responsible to track functional changes for each release in a suitable tracking system to be decided by JRA1 management

EMI 0 and EMI 1

The first two major releases of EMI will be numbered EMI 0 and EMI 1 (the possibility of assigning a specific code name to each release has been in principle approved, but there is no agreement yet of what code names to use). The two releases have very specific uses and follow one after the other

1. EMI 0 is an internal major release to be used to allow everybody to become familiar with the EMI tools and procedures and sort out any dependency and packaging issue before the real development work on EMI 1 starts
2. Configurations for all components in EMI 0 must be in ETICS by the end of September 2010
3. The EMI 0 stack must build consistently and produce installable packages by the end of October 2010
4. In the absence of specific requirements from the user communities at this time, it is agreed that the mandatory platforms for EMI 0 are RHEL5 and compatible distributions on 32 and 64 bits and Debian 5 and compatible distributions on 32 and 64 bit.
5. The EMT is requested to work on this assumption to prepare the release plan for EMI 0 and propose more detailed specifications for the platforms (for example the clients may be released on more platforms like MacOS)
6. Optional platforms can be declared and supported by each PT as needed
7. Services from EMI 0 will be installed in the internal EMI development testbed as the baseline for further development and testing of EMI 1
8. EMI 1 is the first public major release of EMI
9. EMI 1 adds to EMI 0 a number of functional modifications (enhancements, new features, new interfaces) as specified by the JRA1 development plans
10. The technical specifications (development plans) must be released by JRA1 by the end of October 2010, so that PTs can start the development no later than 1 November 2010
11. Code freeze for new functionality and interface changes is scheduled for 28 February 2011
12. General Availability of EMI 1 is planned for 30 April 2011 after two months of extensive testing without any additional functional modifications (only fixes)

User Support

1. In case a PT is developing and supporting at the same time products in the EMI work plan and strictly related products not directly in EMI work plan, the PT is allowed to use the same GGUS support Unit, provided that:
   1. The non-EMI products generate a number of user ticket negligible compared to the the EMI products in the same Support Unit, or
   2. There is a clear automatic way of separating the tickets for the EMI products from those for the non-EMI products in order not to alter the EMI support performance metrics
2. If neither of the above condition is verified, separate GGUS Support Unit must be created
3. The above case may apply APEL and DGAS products, whose responsibility is partially in EMI (clients enhancements) and partially outside EMI (servers)
4. The SA1 leader shall provide statistics of the relative number of tickets for clients and servers for the above products to decide in which category they fall in
5. GGUS can calculate statistics only based on Support Units, not on individual products covered by each Support Unit. It is considered sufficient to report metrics based on Support Units rather than individual Products, since doing otherwise would introduced an excessive amount of manual work, not justified by the actual impact on the evaluation of the Support services and the Product Teams efficiency
6. All EMI products must be supported using GGUS Support Units. A Support Unit can cover one or more products depending on how the corresponding Product Teams are organized. Second-level support teams are requested to assign tickets to the appropriate Support Unit based on their analysis of the support request. In case the second level support cannot assign a ticket to any of the specific EMI Support Units, they will assign it to a special Support Unit called “EMI Generic”. This SU it is not supposed to catch ALL tickets, but only those that cannot be assigned to other SUs. Notifications about the generic tickets are sent to all middleware support lists within EMI. The Support Task Team in SA1 (lead by Mathilde Romberg from Juelich) is responsible to monitor the SU and verify that no ticket remains unassigned for more than a specific time defined by the EMI Support policies. If the number of tickets assigned to the EMI Generic SU is more than 10 per month, the situation will be revised, either by clarifying with EGI why the second-level support personnel is not able to properly assign tickets or by defining load-sharing mechanisms in EMI (shifts)
7. The total number of tickets entering the EMI Support Service will be calculated by summing up the tickets in each SU including the EMI Generic one.

-- AlbertoDiMeglio - 27-Sep-2010