DATE: 14.02.2011

Participants: 
John White, Cristina Del Cano Novales, Giuseppe Fiameni,  Danilo Dongiovanni, Anders Wäänänen,  Andrea Ceccanti,  Björn Hagemeier,  Zdenek Sustr,  Krzysztof Benedyczak,  Paolo Andreetto,  Morris Riedel,  Martin Savko,  Jon K. Nilsen,  Mattias Ellert,  Valery Tschopp,  Marco Cecchi,  Patrick Fuhrmann,  Riccardo Zappi,  Christian Bernardt,  Paolo Andreetto, Lorenzo Dini, Maria Alandes Pradillo, Alberto Aimar, Pedro Andrade, Alberto Di Meglio, Cristina Aiftimiei

Missing: AMGA, gLite InformationSystem, SAGA	

Meeting entirely dedicated to the «EMI 1 “Kebnekaise” release preparation schedule», attached to the meeting agenda, and on the EMT mailing-list

No comment on point 1., 2.
3. no new requirements are defined in the checklist, they are taken from the existing Policies documentation. It will help developers to have a summary of all the thigs they have to do to be able to release components in EMI
5. requested Release Notes should be made available in the EMI-Releases tracker ;
Action on Cristina – to circulate the part refering to the Release Notes contained in the Change Management Policies
6.  by 23 Feb should be deployed on the testbed, and can be used by the PTs to certify their components. Details on interoperability testing will be made available as soon as there is a common aggrement on who has to do/implement them.
7, 8, 9 – different code freeze acording to the criticity of the compoentns

Q (AndreaC):
the deadlines depend on the Packaging Policies. Components that do not respect the “MUST” on the Packaging Policies will be rejected? The possibility to produce src.rpms is not obvious for components that are using maven, they are not conform to EPEL guidelines.
Balasz: 
Testing & Certification done by the PT means: there will be available a checklist; the PT/PT leader will go through the checklist and declares if a component satisfies or not the requirements. By the deadline the PT has to provide a report with the certification status, explaining the reasons of not meeting the requirements. Reports are needed ASAP to be able to evaluate the real situation. What is needed is a code good enough for the RC1 together with the certification report.

Valery: - publishing the requirements this week and asking for the certification in 2 days seems to short
Morris: - the checklist is not fundamentally different from what is available since long time
Lorenzo: 
Friday there was a discussion on what should be put in the Packaging Policies for the best situation, but this doesn't mean that if PTs are not 100% their components will be rejected.
Balazs: Are there strong objections about this strict deadlines? 23 Feb – critical components and 2 March other components
NO objections


10, 11, 12 – RC1 available and deployed on the testbed, QC-team validation and validation reports attached to the EMI Releases tracker 

Q (GiuseppeF): 
the QC in case a PT doesn't respect the criteria - should reject a component and ask for clarification? Who ist  going to evaluate the justification of each PT?
AlbettoA – QC should only report , not to stop a release, The decision is of PEB or PTB
Q(GiuseppeF): QC team has only 1 person
Cristina:
the new “emergency” QC team will be formed with members from NA1 (FloridaE), SA1 (GiuseppeF), SA2 (to be decided) and JRA1 (AndreaC)
Q(GiuseppeF) – SA2 should update the Production Release Criteria
Maria: - it will be ready this week

13, 14, 15 – RC2 ready, available for technical preview, installed  on the testbed
16, 17 – latest dates for components and documentation  from Pts
18, 19, 20, 21 – preparation and deployment of the EMI 1 Release

PedroA:
a lot of time was spend in building components, while the effort on packaging started only few days ago, and this can cause problems
PTs are limited by the infrastructure and the tools; effort was put in improving the etics-client during the last week; more attention should be put on the availability of the tools
Massimo:
for the gLite JobManagement component  that need the modification of the yaim-module can start only when all the relevant components are ready
Danilo:
which are the components will be available on the EMI repository?
Cristina:
on 18 Feb all components that build will be available on the repository

Lorenzo: Communication on the conclusions of the Packaging meeting and info about the new etics-client
Friday (11. Feb) a meeting on Packaging TaskForce took place, triggered by AndersW and other ARC people because they have components already EPEL compliant, and we wanted to figure out how can we let them release those components without maging houge changes in the infrastructure.
Participants: SA1, SA2, PTB and PEB members
The result was a plan for the infrastructure and some policies about packaging
for the infrastructure – everybody agreed that big changes in the infrastructure using other build system is not suitable, especially because we have already under development the new system that was planned for EMI 1, and this is what is delivered this week - the improvements in the etics-client and in the infrastructure are that after the normal ETICS build, a Mock build executes from source packages and regenerates rpms in a pristine environment
another change – provide minimal WN images with minimal packages installed
another change – the etics-client installs the rpms that are defined by the components in order to verify that the dependencies are in place
after the release of the new etics-client (1.5.0) the EPEL-WNs (with all packages) will slowly be replaced  with the new images, and allow to etics-client sudo privileges to install rpms in the image acording to dependencies;
AndreaC:
will the configuration have to change?
The case of maven – that Pts expected be installed in the build-nodes
How do we know that we'll have maven correctly packaged?
Lorenzo:
this is a good reason to not be 100% compliant starting from tomorrow
aware that VOMS and UNICORE use maven and that is complicated to have a maven package soon
Andrea:
will my builds work with the new client?
Lorenzo:
yes, it will continue to work because the build doesn't change
the only difference is that a new option will be added at the end of the Nbs, that enables at the end of the normal build process a Mock process will be executed in a pristine environment, so that the packages that are produced correctly will have a higher priority
at the end of the process there will be a list of packages with 3 colors: red >→ no package exists; orange/yellow –> package was build by ETICS directly to binary; green – the packages work also from source.rpms
the client doesn't break your build, you will have an orange package
this allows people using ETICs to hepp-on using ETICS with small changes, and to ARC people to build in a pristine environment and produce EPEL compliant packages
this new client will be also dynamic for the external dependencies/properties
for the Mock environment, there arre a set of yum repositories that ill be used, in addition to the basic ones (OS, EPEL), add etics-externals – this repo should  be moved to emi-externals
as soon as the rc0, rc1, etc are available, there will be an yum repository, that will be added to the list of repositories used by Mock to pick up pachages.
News: 
The EMI Packagig Ploicies was updated; at the next EMT will be discussed; The doc is still a draft of the project
“What happens if a PT directly publish packages sa EPEL”
This is not allowed, every PT must follow the EMI quality assurance release process to be able to release packages
MartinS:
what happens with packages like lfc, that is already in EPEL, when we will run the repackaging of ETICS , will the version available from ETICS will be picked up or the ones from te EPEL?
Lorenzo:
if there is a version in EMI newer than the one in EPEL, considering that this package will be available from the RC0, RC1 yum repos;
Every dependency will pick-up the newer version in EMI 1; This is the right behaviour
together with Cristina, we are planing a stable testing repository; maybe an incremental repository, so that in case a NB fails, it remains available the previous one.
Massimo – for RC0 what project-config will be used?
Cristina – emi_B_1_rc
Massimo: - you expect tagged software, not branching?
Cristina – yes

Anders: - clarification on the “not allowed to put software in EPEL”
AlbertoDM:
this is not a trivial issue, there were also comments about this, including the WLCG pre-deployment board
what it si not allowed is for a PT to use software created in EMI and to create packages directly to EPEL without going through the EMI procedures
if the outcome of this procedures is to produce packags that are fit for being pushed into EPEL, nobody prevents anybody to do this
we cannot put in EPEL something that is more advanced that we have in EMI repos, that will end up in UMD repos.
Packages that we put im EMI repos and pushed to UMD repos should be exactly the same as the ones in EPEL, or newer, after gone through the EMI procedures.
Summary:
one cannot put in EPEL something that is newer or different from what we release with EMI

QA Policies:
Maria:
the names of the documents changed from Guidelines to Policies, reflecting the fact that Pts MUST follow what is written there
twiki pages will be updated to reflect this change, as well as PDF  files
the “checklist” is a step by step lis of things to do to be able to release in EMI

AOBs:
AndreaC:
what are the raccomendations for yaim, as this is a tool used by most of gLite PTs
Cristina:
EMI is offering support for yaim for the cmponents that already implement it, meaning that if a PT didn't use yaim until now, it shouldn't start now.
 the packaging – the PackagingPolicies must be followed also for yaim.

AndreaC
VOMS is configured with yaim, and many site-admins rely on yaim to cofigure VOMS; in order to comply with Packaging guidelines, yaim-voms has to be repackaged; in order to repackage it needs the yaim-core. The work on yaim can have an impact on the schedule.
It is acceptable that yaim-modules and packages are not compliant with the Packaging Policies for EMI-1
Cristina:
in my opinion it is acceptable;
yaim will have to undergo anyhow internal changes to reflect the different changes in the paths of a lot of components
Cristina:
from the moment the new etics-client is ready, in order tp speed -up the build process, changes will be done to configurations with problems; Everything will be logged in the Emi 1 twiki page.