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).
Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2009-12-01 - OliverKeeble
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback