EGI Verification Wednesday 21 September 2011 11:00 - 12:30 (EGI TF 2011 - Lyon - Room Rhone 5)
**********************************************************************************************

EMI:
Mattias Ellert 
Cristina Aiftimiei
Danilo Dongiovanni 
Giussepe Fiameni

EGI:
Esteban Freire
Michel Drescher
Ivan Diaz
Enol Fernandez

IGE:
Ioan Lucian Muntean 

Presentation - Roll Call:

Enol presentation about QC (20 minutes):

* Enol explains Product/Appliance separation.
* Enol talks about EMI Feedback and response from SA2.
  * Formalization of tests from TP.
  * Giuseppe: Asks about nature of "test" 
  * Enol shows an example from QC definition.
  * API can be incomplete for some appliances.
  * Mixed functional/ non functional criteria.
* Criteria Examples.
* Evolution of Quality Criteria.
  * Cristina: Asks about dependencies or other miscellaneous problems.
  * Enol: An explanation can be appended.
* Quality Criteria Lifecycle.
* Quality Criteria Releases.
* Plan for new QC release:
  * Virtualisation
  * In a couple of weeks.
* More Information (References, links).
* ACTION: Skill matrix should include training information.
* ACTION: Special RT tickets with links to GGUS tickets.
* ACTION: Unify verification report and executive sumary in a PDF file (apart from doc).
* Ivan: Presentation Review about verification process
* Ivan: Introduction 
* Ivan: Overview
* Ivan: Required Documentation
* Ivan: UMD Releases
* Ivan: Ticket Format.
* Cristina: Tickets should be put in a high priority, so product teams can track them.
* Michel: Yes, the priority of the ticket for the verification should be put in top priority to be distinguished. It also must be assigned to Technology Provider to guarantee response time but it does not mean a solution. But TP feedback and DMSU time response is critical.
* ACTION: All the tickets opened must be marked as top priority. So the TPM assign the ticket correctly.
* Ivan: When verification finish, reports are filled and upload to the EGI document database, executive summary is more like a summary of the QCs failed and passed, and verification report contain the Qcs . When the verification process ends RT ticket  is pass to SR or rejected.
* Ivan: Project Metrics.
* Ioan: What period is reflected in the metrics?
* Ivan: Metrics count the working hours time between the start of the verification and the final state of this verification.
* Michel: In sa2 wiki we should put the people who could verify these products and the people who could training courses of these products.
* Cristina: The link to the ggus ticket should be added in the RT ticket, in a special field, it is complicated for me now see the raised ggus tickets.
* Michel: Yes, maybe we would have to collect in one field/area all the related ggus tickets, it would be quick.
* Michel: Cristina, about the verification reports, do you read them?
* Cristina Aftimei: Yes, the SR and the verification reports.
* Michel: The idea was that each verifier provided his own report, in order to see what happened in 5 minutes.

* Ioan: 21h average verification time too big.
  * ACTION: Charting individual product average verification time.
  * It does not affects the project metrics.  
* Ioan: On feedback from Gridway:
  * Phrasing of QC not appropiate:
    * Enol: Working of adapting criteria mapping to Gridway (metascheduler).
  * Possible communication problem because feedback provided on July.
  * Ioan and Michel will talk on the matter.
  * Ioan: Some of the criteria will be applicable on the next revision.
* Giussepe: Asks for better communications on changes of QC to TPs.
  * Enol agrees.
* Danilo: Asks about NAGIOS and SAM testing.
  * Michel: SAM goes by other workflow and has another repository.
  * Enol: Probe testing is partially included.