Search


DASWG LAL Doxygen

Docs

How-To's
Technical
Software Docs
Minutes

Download

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

Participate

SCCB - Software Change Control Board
Edit these pages
Sub-committees
Mailing List
Telecon

Projects

aLIGO Planning
BAYESTAR
DMT
Glue
GraceDB
gstlal
LALSuite
LDAS
LDG Client/Server
LDM
LDR
ligoDV
LIGOtools
LIGOtools
LVAlert Administration
LVAlert
MatApps
LSCGIS
Metaio
NDS Client
OSG-LIGO
PyCBC
PyLAL
LSCSOFT VM

Legacy Projects

geopp
Onasys

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

DATA FORMATS

  1. The FRAME Specification. [ T970130-F.pdf ]
SOFTWARE CODING GUIDELINES
  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 https://wiki.ligo.org/SCCB/WebHome

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 patrick@gravity.phys.uwm.edu]. 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/

$Id: ccb-charter.html 4272 2012-06-15 20:58:44Z xavier $