Skip to end of metadata
Go to start of metadata

This page's proposal was approved by TSC vote on 04/18/19  and defines the process and criteria for BPs to graduate between states and objective graduation criteria.


Powerpoint version of approved proposal




PDF version of approved proposal



The different BP states are shown below:

Blueprint Graduation Review Process

Graduation reviews move a BP between the states of Proposed to Incubation to Mature to Core. 

Termination reviews move a BP from any state to Archived.

In order to make the process both practicable and non subjective a number of criteria (checks) are defined that must be met to graduate for each review.

This document describes the detailed process that the BP's PTL, sub-committees and TSC shall follow to conduct a graduation review.

The process is always initiated by the BP PTL and driven by the Process sub-committee with final approval by TSC vote.

Incubation Review

Current BP state: Proposed

Target BP state after TSC approval: Incubation

An Incubation review is requested by a proposer from any community member.

The Incubation review process is shown below using the criteria  proposed in the "Graduation Review Criteria" section of this page.




Maturity Review

Current BP state: Incubation

Target BP state after TSC approval: Mature

The Maturity review is initiated by the PTL to move their BP from the Incubation to Mature status in an Akraino release. This can occur at any time between two Akraino release dates.

The objective checks for the Mature review as proposed in the "Graduation Review Criteria" section of this page.

Core Review

Current BP state: Mature

Target BP state after TSC approval: Core

The Core review is initiated by the PTL to move their BP from the Mature to Core status in an Akraino release. This can occur at any time between two Akraino release dates.

The Core review process is identical to that for Mature however the checks for the Core review differ slightly as  proposed in the "Graduation Review Criteria" section of this page.


Graduation Review Criteria

This section contains the proposed criteria to replace the current largely subjective statements in the Community Technical Document (Akraino Technical Community Document#3.3.7ProjectReviews)



Current State

(Target State)

Description

Release Quality

Release Numbering

Deliverables / Exit Criteria

Proposal

(Incubation)

Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs.

n/a

n/a

3.3.7.1 Incubation Review:

-    Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters [a checkmark]

-    Project contact name, company and email are defined and documented [presumably at least one proposer]

-    Description of the project goal and its purpose are defined [a checkmark – use the templates]

-    Scope and project plan are well defined [yes to scope, no to project plan]

-    Resources committed and available

-    Contributors identified

-    Initial list of committers identified (elected/proposed by initial contributors)

-    Meets Akraino TSC Policies

-    Proposal has been socialized with potentially interested or affected projects and/or parties (e.g. presented at Community Meeting)

-    Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects and upstream dependencies, those projects are listed in the proposal, and a sponsoring developer in the project has been identified

-       Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project passes the review, the tools chain must be created within one week. Tools encompass Configuration Management, CI/CD, Code Review, Testing, Team Wiki, End Users documentation (not exhaustive).

Incubation

(Mature)

Project has resources, but is recognized to be in the early stages of development.

Alpha (MVP)

0.1 to 0.x

3.3.7.2 Maturity Review:

On a successful graduation the BP HW/SW package is deemed to be Beta-Quality and the BP moves to the Mature stage.

The collective TSC vote as defined in Akraino Technical Community Document#4.4.1TSCDecisionMakingProcess will be based on all the following set of checks being met:


  • Validation lab check:

The BP project contributors have deployed and validated the BP in at least 2 community member validation labs or a community member validation lab and LF CD lab with the exact HW and SW configuration for which the maturity review is being requested. All validation labs are required to connect with Akraino LF CI. Logs on the LF CI servers pushed from each validation lab's CD testing would be used to verify this check. The environment should be reviewed and endorsed by the CI/CD Sub-Committee. [Question : Do we really need to have the CI/CD sub-committee review a validation lab's internal CI/CD architecture? If so how would this be practically done since access to the validation lab will not generally be granted to other community members?]

  • Release inclusion check:

Successful participation in at least two Akraino release periods in the incubation stage [Note : This implies that nothing will be Mature in Akraino R1 - however a PTL could request a maturity review anytime after R1 i.e. Graduation to Maturity would be possible in R2 from 1st June onwards – TSC should confirm that’s what they want]

  • SW quality/functional check:

The SW quality will be assessed as reaching beta according to :

    1. Passing the mandatory set of test cases for all deployed layers using the tools and test set for each layer as defined by the Akraino Validation Framework Validation feature project (Akraino Blueprint Validation Framework) (after TSC approval). This will define minimum mandatory set of test that must be passed for each layer included in BP, plus
    2. Passing any additional test cases defined by the specific BP project as mandatory, plus
    3. Achieving the minimum Security requirements as defined by the Security subcommittee [Note : the mechanism of security testing / review has not been proposed / agreed]

  • HW definition check:

Precise HW requirements and descriptions are defined and included in the BP's documentation (as used in both lab validations)

  • Upstream dependencies check:

Upstream dependencies must be clearly defined

  • Documentation check:

Documentation subcommittee to provide a recommendation on graduation, or if not with items requiring action/remedy.

This check includes verification that any supported APIs are clearly documented

  • Community Health and Stability check:

PTL should provide a summary of contributors and committers and companies and demonstrate growth - Project is active and contributes to Akraino: The project demonstrates increasing number of commits and/or number of contributions across recent releases. Contributions are commits that have been to an Akraino repository project or related upstream project. Commit examples can be patches to update the requirements document of a project, code addition to an Akraino or upstream project repository, new additional test cases and so forth. [maybe create a template, or use something like Bitergia to get some consistent metrics coming into this review].

The PTL should demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.

Mature(Core)Project is fully functioning and stable, has achieved successful releases.Beta0.x to <1.0

3.3.7.3 Core Review:

On a successful graduation the BP HW/SW package is deemed to be GA-Quality and the BP moves to the Core stage.

The collective TSC vote as defined in Akraino Technical Community Document#4.4.1TSCDecisionMakingProcess will be based on all the following set of checks being met:


  • Deployment check:

The BP project been deployed in at least 2 production networks/locations with the exact HW and SW configuration for which the core review is being requested.

  • Release inclusion check:

Successful participation in at least two Akraino release periods in the mature stage 

  • SW quality/functional check:

The SW quality will be assessed as reaching GA quality according to :

    1. Passing the mandatory set of test cases for all deployed layers using the tools and test set for each layer as defined by the Akraino Validation Framework Validation feature project (Akraino Blueprint Validation Framework) (after TSC approval). This will define minimum mandatory set of test that must be passed for each layer included in BP, plus
    2. Passing any additional test cases defined by the specific BP project as mandatory, plus
    3. Achieving the minimum Security requirements as defined by the Security subcommittee [Note : the mechanism of security testing / review has not been proposed / agreed. It is expected the security requirements for a core review be more stringent/extensive than an mature review]

  • HW definition check:

Precise HW requirements and descriptions are defined and included in the BP's documentation (as used in both the lab validations and the production deployments)

  • Upstream dependencies check:

Upstream dependencies must be clearly defined

  • Documentation check:

Documentation subcommittee to provide a recommendation on graduation, or if not with items requiring action/remedy.

This check includes verification that any supported APIs are clearly documented.

[It is expected the documentation requirements for a core review be more stringent/extensive than an mature review]

  • Community Health and Stability check:

PTL should provide a summary of contributors and committers and companies and demonstrate growth - Project is active and contributes to Akraino: The project demonstrates increasing number of commits and/or number of contributions across recent releases. Contributions are commits that have been to an Akraino repository project or related upstream project. Commit examples can be patches to update the requirements document of a project, code addition to an Akraino or upstream project repository, new additional test cases and so forth. [maybe create a template, or use something like Bitergia to get some consistent metrics coming into this review].

The PTL should demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.



  • No labels