Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

The software comprising the pipeline and what it runs is under configuration control. After baselining the code, all modifications to the running code will need to be approved by the Change Control Board. The purpose of configuration control is to understand the code content that affects processing results, and to maximize system uptime by vetting changes that affect reliability.

Process

Proposed changes will be submitted to the CCB with an explanation of the need, changes and consequences. These will can be recorded in blogs (aka "news item", labeled sassoccb) in any space, if desired. Otherwise the content can appear entirely in jira itself. Approval will be recorded here also. Consideration and approval may be done via email, evo meeting or phone depending on the urgency of the request. We will start off by requiring unanimous approval from the board members for the action to be approved.

 Notification of change requests should be emailed to the CCB email list. 

The need should be recorded in JIRA issues, with a trail through to resolution of the issue.

 Here is the recipe:

  • requestor creates a Jira item in the SSC project, leaving the state as "In Preparation". If you have created a news item to track the content of the request, fill the url into the CCB news item url in the Jira issue.
  • once it is ready to go, the requestor selects Submit to SAS-SO CCB from the workflow. This puts it in the hands of the CCB.
  • the CCB determines the "severity" of the request (whether to send to the LAT &/or and Mission CCBs) and changes the priority on the issue.
  • Then the issue is routed to the approriate next CCB or approved (or rejected)
    • if a minor issue, and approved then the LAT CCB is notified of the change
  • if approved, the issue is assigned back to the requestor, who sets the issue to "Implemented", and then closes the issue or the CCB folks do.

 The request should cover the need for the change; the fix; how it was tested; and how it can be backed out.

The software under control is the pipeline itself (database, pipeline code and user interfaces) and all scripts and executables run by the pipeline for Halfpipe and Level 1 processing and ASP. This includes Science Ops and SAS code.

 Once we have approved the request internally, we will forward it to the Mission Office, where a 24 hour turnaround is promised. The request will be made with this form. 

GlastRelease package

A tagged release of GlastRelease will form the core of reconstruction code run in the pipeline. Changes to this release would be performed on a branch in cvs. Inclusion of the tagged packages will be proposed to the gatekeeper (Heather Kelly) who will prepare new releases. These are based on tested GlastRelease releases as much as possible. System tests will be run. There should be an Science Ops meeting presentation demonstrating the evidence - system tests plus jira issues. Indviduals should represent their changes at these meetings (note: this did not work in I&T!)

...

The board is composed of Richard Dubois (chair), Eduardo do Couto e Silva , Bill AtwoodSteve Ritz, Rob Cameron, Analysis Coordinator (Julie McEneryNicola Omodei), C&A Lead (as needed; Luca Latronico and Philippe Bruel). email traffic for the board can be viewed here. Nicola Omodei will act as CCB chair in Richard's absence.

CCB Actions List

CCB Actions