Separate distribution of the analysis code (and more) P. Hristov 19/03/2014

Reminder 2  After a lot of discussions in PWGs (and outside) Jan Fiete presented the proposal on 10/02/2014 presented  Motivation  Some parts of AliRoot change more frequently than others  AN tag often only for analysis code  Proposal  Split AliRoot into two parts  PWG = (PWG, PWGCF, PWGDQ, …): 9 folders in total = 0.3 GB  CORE = STEER, subdetectors, OCDB, OADB, ANALYSIS, etc.: i.e. everything else = 0.9 GB  Separate repositories  Separate tagging  CORE for example monthly, or on request  PWG twice weekly (like AN tags now)

Reminder: Tagging  Separate tagging, for example  CORE for example monthly, or on request  PWG twice weekly (like AN tags now) CORE v1 PWG v1 GEANT3 ROOT PWG v2 PWG v3 PWG v4 PWG v5 CORE v2 3

Reminder: Some Comments  Advantages  Stable CORE part  Regular PWG tags lead to faster build & smaller archive  Committers to PWG don't need to update CORE part on each commit  Implications for users  Need to download one package more  Detector developers may not need PWG package  Need to build one package more  May build into same directory, no change in includes, library path required  AliRoot download script can do this transparently  Implications for train operators  Selection of PWG tag instead of AliRoot tag, dependencies automatic  Decision: split the PWG code in a separate package after QM 4

Discussion 5  The main question is how we keep consistency between the packages  Other experiments use Code Management Tools: quite heavy  The versioning can be improved and the dependencies between the packages described in a way similar to what RPM and deb do  The solution should be extensible to the external packages (Geant3, Geant4, BOOST, CGAL, FASTJET, etc.)  We can use the FairRoot way of distribution

FairRoot distribution method 6  “Meta-repository” for the external packages + compilation macro (configure.sh). Example: dec13 release (or FairSoft from github)  Git  HepMC  Millepede-II V  ØMQ  CMAKE  BOOST  ROOT  Geant  Geant 3.21 v1-15  Geant4_VMC v2-14a  VGM v3-06  PYTHIA  GSL 1.15  GTEST  PLUTO 5.37  PYTHIA  Core package (FairRoot)  Experiment specific code, i.e. CbmRoot

Proposal for a new AliRoot distribution method 7  Meta-repository for the external packages + installation script  Links to the needed versions of the original distributions: repositories, tarballs, etc.  ROOT  Generators  Transport packages & VMC  Additional software  Patches for the original distributions  Distributions, not available in original form (i.e. DPMJET)  Interfaces to packages (i.e. THijing)  The versions in each release will be decided on a dedicated offline meeting taking into account the requests from the PWGs  Core package (STEER, detectors, ANALYSIS, etc.)  Analysis package (PWG, PWGXX)

Benefits 8  Clear set of versions for each release of external packages, core and analysis  Easy introduction of new external code  Clear set of patches (now they are on the build server, but rarely people take them)  Low/high frequency of changes => low/high release frequency  Smaller distribution size for the frequently updated code (PWG analysis)  Easier installation  Better access control and notification

Plan 9  Analysis packages (2-3 weeks)  Split git repositories  Split cmake files. Profit to implement the “native CMake build”, if not yet done  Adapt build server  Adapt train system  Adapt MonALISA scripts  Adapt AliRoot download scripts  Adapt documentation  External packages (2-3 weeks)  Prepare list of external packages with their versions, interfaces, patches, etc.  Create the meta-repository and the compilation script  Extensive tests on different platforms  Adapt the build system  Modify the versioning in CORE and introduce the requirements for the external packages  Exclude the existing external packages from CORE  Documentation  CORE (1-2 weeks)  Modifications in CMake build system and the servers