Comments on SPI

General remarks Essentially all goals set out in the RTAG report have been achieved. However, the roles defined (Section 9) have not been centralized leading to duplication of effort and several people having problems learning and adapting tools consistently. Good overall perception and take up of service in particular Savannah portal, External packages, QMTest framework Not clear what is interaction with other LCG areas SPI should provide service to all

CVS service Encourage to move to IT central service ASAP (if test satisfactory – otherwise make IT satisfy the requirements) use centrally maintained tools

Savannah portal Very well received, impressive take up Concerns about scalability Can it scale to ~50 contributions/day/project (c.f. root-talk) Avoid future divergence of CERN customisation from mainstream Savannah by close collaboration with authors (looks promising)

Documentation Very impressive and complete web site Workbook will require continuous maintenance to be kept up to date Need a documenter Quality (existence) of doxygen comments should be part of QA tests

External software Recognise professional quality of external software repository Require more transparent decision-making process for provision and maintenance of external software Well identified “owners” – who requested/needs/uses a given package Documented procedure for interacting with users and authors to report/follow up bug fixes Management of versions and dependencies via Architects Forum -Approval of new external package dependencies -Agreement on version changes – ideally freeze version for ~6 months except for well justified critical bug fixes Policy needed for handling differing structures and conventions of external packages in a consistent way -(the structure of the package itself should not be modified) Suggest making available compilation/installation scripts as well as installation logs Suggest simple QA tests for external packages -e.g. to spot configuration changes in new versions

QA QM Test framework well received Policies vs. tools – time to put more emphasis on tools to facilitate compliance? As projects become mature and are deployed, need person centrally responsible for QA to chase projects to improve compliance Should be fully automated (“nightly QA”)

Build system and infrastructure (1) Concern about long term maintenance of NICOS – institutional commitment? Role of central librarian There should be more centralised services across projects -Common build settings -Common release procedures -Sharing of build+release tools -Should not be developed within projects (c.f. POOL) Some of the problems perceived by developers with configuring *any* build tool may be mitigated by delegating to a common librarian

Build system and infrastructure (2) Is nightly build model correct? POOL seems to prefer very frequent internal releases -Which facilitates experiment integration Developers need simple tools to test compilations on other platforms -Without waiting for nightly build How thorough are nightly build tests? -At least compilation should be run on all platforms -Including Windows, need build service -Who checks the output? Encourage procedure in which pre-releases are exposed to users, before freezing the official release

Build system and infrastructure (3) Acknowledge problems with SCRAM build functionality Would be a big advantage if external contribution to LCG software development did not require installation of non- standard tools Support autoconf/automake investigation What is foreseen effort to provide complete functionality? Suggestions for improvements -E.g. abandon recursive makefile -Discussion with C.Arnault & S.Ashby & F.Rademakers to validate ideas Careful study – what additional functionality do SCRAM & CMT provide? Not clear what long term strategy is -Do not use several tools (autoconf/automake+SCRAM+CMT) -Will something other than autoconf always be needed to configure environment? Does it make sense to hold SCRAM course just yet? Welcome acknowledgement of CMT importance in Atlas and LHCb

Distribution More interaction needed with LCG grid deployment area to develop common distribution tools (pacman?) Need tool to generate corresponding (pacman) configuration (exists in CMT) Concern about granularity of existing distribution Need customizable installation/distribution kits for specific components/platforms