Chartering a Consolidation

Chartering a Consolidation

Consolidation Orders
Template Version 1.1

 Overview

	This document creates a C-Team, and describes the general
	parameters and constraints of its operations.  C-Teams are
        responsible for creating and maintaining a source tree branch
        that contains a specific release taxonomy named instance of
        the Community Group's consolidation.

	These Consolidation Orders are limited to the specific release
	commissioned by the orders.  Although Consolidation Orders are
	expected to follow a general pattern when applied to comparably
	structured consolidations, the sponsoring Community Group may
        vary the specific parameters to suit various needs of the
	consolidation.

1.  Introduction

    1.1. Project/Component Working Name:

	// title and ARC case number

    1.2. Name of Document Author/Supplier:

	// The Sponsoring Community Group

    1.3. Date of This Document:

	// MM/DD/YYYY

    1.4. Name of Major Document Customer(s)/Consumer(s):

	// The C-Team Leader commissioned by these Consolidation Orders.

2. Name and Classification of Deliverables

	// Here you put the release taxonomy name of the consolidation
	// being commissioned.  For example: "Foobar 5.3.2"
	// The name implicitly identifies the class of deliverables that
	// maybe included in this consolidation release: major, minor or
	// micro

	// Train model:
        // All Projects of this class (and contained classes) which are,
	// or become completed during the duration of the Consolidation are
	// expected to be included in the consolidation subject to
	// risk-management policies established in the resulting
	// Consolidation Plan.

	// Not Allowed:
        // Components of a higher release taxonomy class than that
	// permitted by the chosen taxonomy binding may not be included
        // under any circumstances.

	// "Must Have's":
        // In addition, components which the Consolidation's risk
	// management policies may not exclude may be specified here. The
	// specification may be component name, by description permitting a
	// set of components, or by other means determined by the Community
        // Group. Any component identified by name must be an accepted
	// Project as of the date of these Consolidation Orders. 

        // "General requirements"
        // In addition, specific conditions to be satisfied by the class 
        // of deliverables can be outlined here.

3. Schedule

	// A description of the period over which components may be
	// selected for inclusion in this consolidation. In addition, a
	// deadline by which the release must be available for release.
        // For example: 
	// Accept deliverables starting April 1st, 2010 and closing no
	// later than November 1st, 2010. Release to be available for
	// distro use not more than 2 weeks after that date.

	// The C-Team will provide schedule details as appropriate.

4. Inclusion Base

	// In developing this section of the document, please consider the
	// following: this is the taxonomy binding of the consolidation (or 
        // list of consolidations) which must be subsumed by this release. 
        // While in general this should be obvious (i.e., all preceding
        // releases are subsumed), this may in practice be impossible to
        // achieve. For instance, consider the release sequence 
        //       4.5, 5.0, 5.1. 
        // Although the CG may wish to obsolete 4.5 upon shipping 5.1,
	// external commitments may require the creation of a 4.5.1
	// after 5.1 has shipped (think security bugfixes). The 
        // deliverables to 4.5.1 may not be applicable to 5.1, either 
        // because the problem no longer exists or because a different
        // deliverable is required due to other changes in 5.0 or 5.1.

5. Delivery Formats

	// In developing this section of the document, please consider the
	// "Release Names" section of the Release Taxonomy.

	// In this section, all of the values for architecture and format
	// that will apply to this release should be called out.
	// For example: myFoo 2.11 will support both x64 and SPARC 
        // architectures, and will be delivered as
        //     a set of pkg(5)'s in a repository
        //     a tagged mercurial changeset 

6. Validation Requirements

	// In developing this section of the document, please consider the
	// following:
	// In order to complete the release, the C-Team must validate it
	// using Test-o-Mat. In order to ensure that the quality of the
	// product is assured through release, the orders will specify a
	// validation level that the release is to achieve.
	// The validation level requirement dominates Schedule unless
	// specifically directed otherwise either in this section or in an
	// amendment issued by the Steering Committee.

7. Additional Information

	// Additional information to guide the activities of the C-Team may
	// be provided as seems necessary or prudent. Such information
	// might be: 
	//     i) the form or period of status reports to the CG.
	//    ii) the identification of specific resources available for
	//        the C-Team (servers, repositories,...).