gLite 4

Note : all information here currently has the status of a proposal and is under discussion.

The next release of gLite will be called gLite 4 and will be available on SL5/x86_64, Debian 5 and other platforms.

gLite 4, steps and decisions required:

• Define external dependencies
  • Decide EPEL/DAG
    • Equivalents on other platforms?
  • Versions of Condor, VDT...
  • VDT build and rpm versioning strategy
  • Version of java, tomcat...
  • Versions of other externals (gsoap etc)
• Define gLite SDK
  • Define its scope - how much 'internal' API should be exposed?
    • Suggestion - as soon as something is used by a different product team from the maintainer, it is considered part of the SDK and part of the 'public interface'
  • For gLite 4, this is the core API on which must be defined before other components
  • For gLite 3.2, this is the core which will see minimal change during the release lifetime
  • It will also be released as a node-type to allow easy building by third parties
• Define expected services
  • Anything to be added or removed?
  • Priorities (WN, UI...)
• Define acceptance criteria for packages
  • New packaging proposal (ie conformance with target platform guidelines)
    • Requirements on ETICS
  • Deployment tests in ETICS - at what level?
    • who implements them?
  • Conformance of ETICS configs to guidelines
  • What level of source - working SRPMs?
  • Conformance with previously agreed release schedule
  • existence of a user guide, a sysadmin guide, API reference, etc. (when applicable).
• Define upgrade policy
  • Will we support upgrade gLite 3.2 -> gLite 4.
    • is this compatible with changing the packaging?
    • JRA1 proposes no upgrade path
• Create gLite 4 project configuration in ETICS
  • Attach all possible platforms
  • Set up nightly builds
  • Supply all externals
  • One big project, or numerous smaller ones all depending on the SDK?
• Release Process
  • Currently envisaged to be like the one described by Francesco
  • How to know when its prerequisites are met?
  • How do we manage the transition from one to the other?
  • How long will gLite 3.2 be supported?
    • And at what level?
    • Can fixes for bugs of severity < major all be put into gLite 4?
    • Proposal : we support it until needed for WLCG, making it as stable as possible for the basic components (VOMS, LCAS/LCMAPS, etc.) and allowing changes in high-level services according to WLCG needs. New things would go in gLite 4 (and EMI).