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

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”

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

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 ?

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