Comments on SPI

1
Comments on SPI
2
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

3
CVS service

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

4
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)

5
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

6
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/use
  s 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

7
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)

8
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 buildrelease 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

9
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

10
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/automakeSCRAM
  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

11
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