1. Providing a coherent view of SFT products to potential new users Stefan Roiser PH/SFT

2. What happened so far … 3 March 20102SFT Program of Work Multicore What SFT provides: Web Documentation Build Tools Testing Infrastructure Software Distribution Code Documentation “Computing Knowledge” Issue Tracking Integrated Releases LOTS OF SOFTWARE: Simulation MC Generators Data persistence Graphics Databases Scripting Languages Grid Middleware Detector Description Foundation Math Tools X Compilers X Architectures X Operating Systems Support for LHC in a good shape ? Can we attract also new users? More than 100 sw packages organized in “SFT Releases”

3. Ways to discourage users Incoherent software infrastructure –Too many ways to build our software Configure/Make, Makefiles, CMT, scram, … –Deployment possibilities Not needed for LHC but for others? –Runtime setup Outside CMT not usable Documentation / Information –It is there but spread over many different areas Project pages, twikis, dynamic pages, –-> Effort started to use Drupal based web infrastructure 3 March 2010SFT Program of Work3

4. A proposal for the sw infrastructure 3 March 20104SFT Program of Work Common build Infrastructure for all SFT software packages Configuration Management Native deployment methods per supported platform Runtime setup for all software pkgs within a “SFT release” one for all: e.g. cmake, cmt, waf, … one per supp. OS: rpm CVMFS, PkgMaker, … native scripts from config. mgmt. 3 concepts: Use common tools throughout SFT Decouple build and runtime Go native when necessary Advantages: Coherent view across all SFT constituents Simplification of usage for new users Taking load from LHC users for deployment ?

5. Conclusion We are ε away from a “SFT corporate identity” –Use common tools within our group –Simplification of our sw stack with only few measures –Huge potential if we all participate Lots of power but wrong chassis 3 March 2010SFT Program of Work5