Software Docs


Browse CVS, Git, or SVN
Software Repositories
OS Security Updates
LIGO software virtual machine
VMware SL6 Install


SCCB - Software Change Control Board
Edit these pages
Mailing List


LDAS Tools
LDG Client/Server
LVAlert Administration
NDS Client

Legacy Projects


Software Change Control Board [SCCB]

Table of contents

  1. CCB Members
  2. Controlled specifications
  3. SCCB LSCSOFT Repository Management
  4. CCB Charter

CCB Members:

The LSC Software Coordinator (in consultation with the LSC spokesperson) will appoint the members of the CCB. Currently, they are:

  1. Stuart Anderson
  2. Jolien Creighton
  3. John Zweizig

Specifications formally under the CCB's purview (as of Oct 2004):


  1. The FRAME Specification. [ T970130-F.pdf ]
  1. LSC Data Analysis Software Practices (draft) [ PDF ]
  2. LAL Specification. A new version is under consideration and will be coming soon

SCCB LSCSOFT Repository Management

LSCSOFT package movements is managed from the foswiki page at

CCB Charter

  1. The purpose of the CCB:

    The LIGO Lab and the LSC have adopted software specifications that are intended to foster widespread use and collaborative development of well-tested analysis packages. In order to meet this goal, the software and software specifications must remain reasonably stable so the ground won't be shifting under the developers. On the other hand, as real problems are identified, changes may need to be made. The charge to the CCB is to strike a balance between stability and flexibility of the software. They should do this by adding order, common sense and some inertia to the change process. The purpose of this charter is to lay out how the CCB should operate.

  2. The software governed by the CCB:

    The LSC Software Coordinator in conjunction with the LSC Executive Committee will decide what is to be governed by the CCB. The list of items that are formally under the charge of the committee are appended to this document.

    As a general rule, the initial drafting of software specifications should be done by working groups and not by the CCB. Only after the specifications have had some field testing should they be placed under the purview of the CCB.

  3. Procedure for requesting a change:

    An individual or group should submit a written (email) request for software changes to the LSC Software Coordinator [currently]. In most cases, this should be a light-weight, one-page email. The request should include:

    1. a description of the change.
    2. the rationale behind the requested change, including the (dis)advantages of (not) making the change.
    3. an estimate of the impact of the change on other systems and software.
    4. a plan for implementing the change that addresses who will do the work.

  4. The criteria for making a change:

    The change should be adopted if the benefits outweigh the costs of making the change.

  5. The CCB decision process should include:
    1. iteration with those requesting the changes.
    2. technical input from the CCB itself, or others the CCB feels should be consulted.
    3. an assessment of the impact of (not) making the change.
    4. input from the Lab and the LSC hierarchy, as well as other projects (GEO, VIRGO, TAMA, etc.) that might be affected by the change. In particular, the CCB will work with the Lab to honor agreements with other projects that pertain to jointly maintained software specifications.
    5. input from the code developers that might be affected by the change.
    6. the viability of the plan for implementing the change.
    7. common sense.

    The committee will try to reach a consensus on whether the change should be adopted. In the absence of a clear consensus, the board will formally vote on the changes. The software coordinator will break tie votes.

  6. Responsibilities of the LSC Software Coordinator in the CCB process:
    1. Make sure that requested changes move through the process, i.e. pass the information to the committee, convene the meetings, etc..
    2. Set the pace and priorities for the decision process. Some changes are urgent, others are trivial, and still other things can (should) wait.
    3. Inform the Lab Directorate and the LSC spokesperson what changes are before the committee. This is to insure they have an opportunity for input regarding scheduling and coordination with other projects.
    4. Insure that the rank and file programmers are notified and have a chance to comment on significant changes.
    5. If the CCB concludes that a change should be made, the Software Coordinator will act on behalf of the LSC spokesperson and LSC Executive Committee to see that the change is carried out.

Maintaining this document:

The LSC Software Coordinator will maintain this document in the DASWG web CVS archive. The most up to date version can be found at Docs/