Hi all,
  
  thanks to all of you for the helpful discussions at the last
  weeks Technical Forum! This mail tries to summarize the various
  aspects of the discussed SAGA release procedure, as I would
  like to get reconfirmation that this procedure is correct,
  and will be accepted by the respective stakeholders.
  
  
  SAGA software packages:
  -----------------------
  
  The SAGA project plans to release the following components to EGI:
  
   - saga-core            (SAGA C++ API bindings and implementation)
   - saga-bindings-python (SAGA Python API bindings, wrapper over C++)
   - saga-adaptors-glite  (service discovery, info navigator, cream jobs)
   - saga-adaptors-globus (gram, gridftp, rls)
   - saga-adaptors-ssh    (ssh_job, ssh_file)
   - saga-adaptors-bes    (BES HPC Basic Profile)
   - saga-adaptors-x509   (X509 credential handling support)
  
  All components depend on saga-core; saga-core depends on boost,
  postgresql client libs, and openssl.
  
  
  Release procedure:
  ------------------
  
  Instead of implementing our own release, testing, certification
  and repository infrastructure, we plan to leverage the processes
  which are in place for IGE and EMI.  As IGE will not support the
  build and test of the gLite adaptors, and EMI will not support the
  build and test of the globus and bes adaptors, we have to split the
  components.  In terms of dependencies, that would require saga-core
  to show up in both repositories (IGE and EMI).
  
  In order to resolve that, Bjoern and Alberto suggested the
  following procedure:
  
   - saga-core is build, packaged, tested and certified in the
    IGE process
   - the saga-core RPMs are then provided via some repository, and
    copied as external dependencies into ETICS (which represents
    the EMI process for us)
   - the gLite adaptors would then get build and packaged in ETICS,
    against the external saga-core dependency
  
  
  That way, we keep the EMI load lightweight (it seems to be the more
  difficult process for us), but are able to satisfy all dependencies
  cleanly.  The UMD will at the end pull the various SAGA modules
  together, from the two upstream repositories.
  
  For clarification: for the time being, all responsibilities for
  development and ticketing seem to stay with the saga-project, for all
  components.
  

  Status:
  -------
  
  We are at the moment producing source and binary RPMs for all
  components, and plan to enter the testing and certification phase
  in the IGE process next week (in alignment with the IGE release cycle
  I hope).  I am not sure about the exact time lines on the EMI/gLite
  side of things, but it should not be far behind.