Version 54 (modified by robyn, 7 years ago) (diff)


DM Technical Control Team

from: LSST Data Management


  • Robyn Allsman - Chair
  • Mario Juric
  • Kian-Tat Lim
  • Robert Lupton
  • Serge Monkewitz
  • Russell Owen
  • Ray Plante
  • Gregory Dubois-Felsmann (ex-officio)


The DM Technical Control Team (TCT), formerly known as the DM Configuration Control Board (CCB), reviews and approves changes to all baselines in the LSST Data Management System, including proposed changes to the DM functional requirements' (FRS), reference design, or Data Challenge design baselines, the tools to be used, and standards and policies.

The following mandate established the TCT:

  • The board is chaired by the DM System QA and Test Lead.
  • Members include DM System Scientist and Lead Institution Project Scientists.
  • The board determines when specification and deliverables are of sufficient maturity and quality to be baselined (placed under configuration controlled status) or released.
  • The board reviews and approves proposed changes to baselined items.
  • The board meets at least monthly and more often during periods prior to major reviews and data challenge integrations or when development requests approval to change baseline.

The Technical Control Team and the System Architecture Team work in synchrony. The SAT (and the various DM team members as delegated) is responsible for creating, establishing, updating, analyzing, proposing the reference and DC designs and changes to them, whether they might affect the FRS, the reference design, or the DC design. The TCT makes sure these changes don't get into the baseline without proper change control. The TCT must involve PM before approving an FRS change, as this might affect the project schedule or cost envelope. Restated more simply, the FRS is baselined, and the Reference Design are baselined, and so should each DC design be baselined. The SAT defines them, the TCT controls baselining and acceptance of changes to the baseline for all 3.

For further clarification, refer to pre- and post-baseline duties.

Initiating a Software Policy/Procedure/Design Change

Prepare either a wiki document or a Trac Ticket describing the proposed change. For a wiki document, invite on-line comments to be entered within the wiki document by inserting the [[[AddComment]]] macro. FA proposal initiated via a trac ticket shuld be referenced to component TCT and directed to developer robyn.

Advertise your request for timely comments on the new proposal to the LSST-data mail group with a complete URL in the message. Also, update this TCT page by including the wiki pointer to your proposal under the section heading "Proposals for Future Review". Allow an adequate comment period (a week or so) prior to the TCT meeting at which you want the topic discussed.

Be prepared to discuss the pros and cons of your proposal at the next TCT telecon. If the proposal is to add/upgrade/remove software from the stack, the TCT will not only discuss the proposal, but the feasibility and schedule of implementation, before approving the change. If there are significant schedule impacts that cannot be resolved the TCT will escalate the issue to project management.

Meeting Schedule

  • Next meeting: Thursday 17 January 2013 from noon-1:00 PT - if there are topics to discuss

Agenda of 17 Jan Meeting

  • Ticket Workflow - Paul's Ticket #2548 proposes the addition of three new flows to the Ticket Workflow. K-T suggests that we should take the time to optimize the Workflow experience for Developers. At the TCT meeting, we will take 15 minutes to develop a reasonable simplification of the workflow. However if we can't agree in those 15 minutes, we will simply adopt Paul's fix.
  • Style Checker proposal - See Ticket #2553. We will lead with a discussion on whether instituting routine style checking should begin now or at later date. If we decide to start style checking now, the recommendation is to use Steve Bickerton's which covers 50 of the 123 DM rules. Steve annotated each ignored rule with comments on outright impossibility, ambiguity, level of difficulty, etc. Another tool examined in detail was Google's cpplint which needs lots of work to have it conform to our style specs; it covers about 43 DM rules.
  • Address the renaming of Trac components to highlight which are obsolete. There is some question as to what might happen to historic Tickets, etc. if a previously defined component was deleted from the current component list. I suspect we could do a quick vote on:
    • remove component name if the DB doesn't wipe out the component's name from historic Tickets; or
    • rename an obsolete component to some variant of: obsolete_<component>, dead_<component>, NA_<component>, etc. I will report what happens when I create a new component, make a new ticket referencing it, and then delete that component.

Proposals for Future Review

Create either a

  • [wiki:DM/Policy/PointerToProposal], Author, Date <- Note 'DM/Policy' prefix in name; or
  • a Trac Ticket on component TCT.

then list your proposal here:

  • ...
  • ...

Action Items

Past Meetings

Notes from past meetings are available at DM/TCT/meetings.