This is a high-level document describing, in general, the development process for all IceCube software efforts.
This is not project specific but describes the essential documents, roles, tools and specifications which must exist in all software IceCube efforts.
The following documents must exist for each software effort. These docs will refer to each other and may be revised and/or specific to each release.
This identifies the goals of a specific release: what is being fixed, added or removed, if this is a major or minor release, etc. It identifies who certifies the release (based on successful execution of the Test Plan), and how that release is deployed/distributed, recorded and announced.
This a per-release document which details the the set of tests to be executed, who executes them and who verifies their runs.
A schedule of development milestones and responsible parties, including full, minor and patch releases.
Various tools which need to accomplish the following tasks will be used by each IceCube software effort.
Which of cvs, svn, or bfd is used is less important than that release candidates and certified releases can be rebuilt from known tagged/delivery points. In conjunction with the below described environments, a release should be completely reproducible.
A database for tracking bugs and feature requests. This can also be used for more than just tracking defects but also for tracking schedules and project management.
A definitive and authoritative mechanism of identifying deviations from the correct configuration of the below described environments - including the underlying system, dependencies and IceCube software itself. This is to provide an automated and relatively objective way to insure that the configuration of the environments is intact.
Each software effort needs to identify the specifications required for the various environments used in their projects. These include at a minimum the following environments.
Detailed description of the environment in which the software is expected (and has been certified) to run. For some projects this may be one and only one systems (i.e. the SPS) for others is may be many different workstation platforms.
Detailed description of the specific machine (or set of machines) where the released software is compiled into it's distributable form (binaries, rpms, etc.). This environment will need to be compatible with the execution environment(s).
There will likely be multiple testing environments (for various tests and platforms) but for each one a specification should be created for accuracy and reproducibility of tests.
This is potentially is the most flexible environment but a minimum specification of a developers 'sandbox' should be documented. Not only to identify supported development platforms but also to aid in developers coming up to speed.