Process, Project review and recommend sub-committee: Finalize request Templates for Blueprint and feature project, document to allow developers to get started. Develop and evolve the process by which blueprint and feature project proposals are reviewed, and ultimately approved with recommendation required documentation.
Sub-Committee Chair - Jim Einarsson. Elected 11/14/2018
Template 1 - Use case template
Template 2 - Blueprint family template
Template 3 - Blueprint species template
Please join the Process Sub-Committee mail list by self-adding within the Akraino Mail List Sub-Groups page.
Note: Please ensure that both the name and email address for each member is listed on each sub-committee membership wiki page in order to properly set up CIVS voting when required.
Interested parties sign up:
Name | Affiliation | LF ID | |
---|---|---|---|
Tina Tsou | Arm | tina.tsou@arm.com | |
Tapio Tallgren | Nokia | tapio.tallgren@nokia.com | |
Frank Zdarsky | Red Hat | fzdarsky@redhat.com | |
Jenny Koerv | Intel | jenny.koerv@intel.com | Jennifer Koerv |
Deepak S | Intel | deepak.s@intel.com | |
Qasim Arham | Juniper | qarham@juniper.net | |
Andrew Wilkinson | Ericsson | andrew.wilkinson@ericsson.com | |
Sukhdev Kapur | Juniper | sukhdev@juniper.net | |
Wenjing Chu | Huawei | wenjing.chu@huawei.com | |
Wenhui Zhang | Penn State | wuz49@ist.psu.edu | |
Gerry Winsor | Nokia | gerald.winsor@nokia.com | |
Kandan Kathirvel | AT&T | kk0563@att.com | |
Adnan Saleem | Radisys | adnan.saleem@radisys.com | |
Jim Einarsson | Wind River | jim.einarsson@windriver.com | |
Jack Liu | Arm | jack.liu@arm.com | |
Ryota Ishibashi | NTT | ryota.ishibashi.xy@hco.ntt.co.jp | |
Hiroshi Yamamoto | NTT | hiroshi.yamamoto.pz@hco.ntt.co.jp |
Jenny raised the question – is the inclusion/exclusion of the word “Akraino” in the BP/FP name meaningful?
State | Description | Release Quality | Release Numbering | Deliverables / Exit Criteria |
Proposal | 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 [need to define what these are? – Bill to find out what these are – Jenny’s chasing down some language about this] - 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 | 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 x.x.x.> will be based on all the following set of checks being met:
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 validations labs are required to connect with Akraino LF CI.
Successful participation in at least two Akraino release periods in the incubation stage [this implies that nothing will be Mature in Akraino R1 - however a PTL could request a maturity review anytime after R1 i.e. from 1st June onwards – TSC should confirm that’s what they want]
The SW quality will be assessed as reaching beta according to :
Precise HW requirements and descriptions are defined and included in the BP's documentation (as used in both lab validations)
The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy. [How practically will this be judged?]
Upstream dependencies must be clearly defined
Documentation subcommittee to provide a recommendation on graduation, or if not with items requiring action/remedy.
API subcommittee to provide a recommendation on graduation, or if not with items requiring actions/remedy.
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]
|
We discussed the following table, which expands on what’s already there in section 3.3.4, and adds…
Release Quality
Release Number
Deliverables / Exit Criteria
The intent is to simplify this section, putting everything in one place. We got through the first two states this week...
State | Description | Release Quality | Release Numbering | Deliverables / Exit Criteria |
Proposal | 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 | From 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 [need to define what these are?] - 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 | Project has resources, but is recognized to be in the early stages of development. | Alpha (MVP) | 0.1 to 0.x | From 3.3.7.2 Maturity Review: - PTL & Committers are in place. - Beta-Quality Release Achieved [we need to double-click on what the definition of Beta quality is – FOA, POC, end of release?] - Successful participation in at least two releases: The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy. [this implies that nothing will be Mature in Rel 1 – TSC should confirm that’s what they want] - Architecture has been reviewed by the CI/CD Sub-Committee, TSC and presented to broader Akraino community [why have the CI/CD Sub-Committee review the architecture – the next point should cover this] - Project Contributors have provided a validation lab [should be 2 labs] with exact configuration required by the project to connect with Akraino CI and demonstrate CD. The environment should be reviewed and endorsed by the CI/CD Sub-Committee. - Acceptance Tests: who & when do we validate the acceptance tests for the BP? - 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 test cases and so forth. [maybe create a template, or use something like Bitergia to get some consistent metrics coming into this review] - Mature artifacts produced: The project demonstrates that the artifacts produced by the project are deployable (where applicable) and have been successfully deployed, configured and used by at least two independent end users typically, service providers who have publicly documented their support on the Akraino wiki and within the accompanying project documentation. [considering moving this to Mature, since it’s quite deterministic, and consider adding a point here that the project needs to state how many independent deployments it has] |
Mature | Project is fully functioning and stable, has achieved successful releases. | Beta | 0.x to <1.0 | From 3.3.7.3 Core Review: - Contributor diversity: The project demonstrates that it has a stable core team of contributors/committers which are affiliated to a set of at least three different companies. Core team members are those who have been active on the project for more than two releases, which means they were reviewing contributions to the project in Akraino Code Review and/or in the review-tool of the target upstream project(s). - Recognized value through other projects: The project demonstrates that its results are leveraged by other Akraino projects in an ongoing way, i.e. for at least the last two releases. - Successful integration tests (only applicable to projects which provide features/functionality): The project demonstrates that component tests and system-level tests have been implemented, that tests are used within the Akraino CI/CD test pipeline, and that tests bear successful results. - Stability, Security, Scalability and Performance levels have reached a high bar. Also? - GA-quality release achieved, per Validation Feature Project - project has 2+ adopters |
Core | Project provides value to and receives interest from a broad audience. | GA | 1.0+ | From 3.3.7.4 Termination Review: - Artifacts for Core state are complete and accepted - Core project artifacts are acceptable and meet the acceptance criteria - Project Team has the confidence that its artifacts can be used outside the Akraino community - Metrics for Termination review are available |
Archived | Project can reach Archived state for multiple reasons. Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical, etc.). Project in any state can be Archived through a Termination Review. | Deprecated | 1.0+ | n/a |
Attendees
Release Cadence
Proposed Changes from Last Process Sub-Committee Meeting
More Proposed Changes
Checklists for Graduation
Attendees: Jim Einarsson, Tina Tsou, Tapio Tallgren, Andrew Wilkinson, Bill Zvonar
Trouble Starting the Meeting
Review Feature Project Template (per last TSC)
TCD Changes re: PTL/Committers & Project “Start”
didn’t get to these agenda items, will table them for next week’s meeting
Attendees: Tina Tsou, Jenny Koerv
Formal motion at next TSC meeting to vote on action to revise
Ask for TSC to review the following as considerations for Maturity Review criteria:
The advantage and desire to have a simple graduation splash page on the Akraino Wiki (Under Process Sub-Committee or otherwise). That simply outlines the Project LifeCycle and Graduation criteria (comparable to the CNCF page here: https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc ). Jenny to take a stab at it…
The need for the TSC to agree on detail language of Review votes for graduation (Majority? 2/3?). The follow up need to document that the TSC vote is to determine whether Criteria have been adequately met for advancement. Note: Jenny afterthought – did not formally get to this in this meeting.
Should section 3.3.7.3 Core Review include the Conformance language? Should Conformance badge warrant the “Akraino” brand and define the “Akraino” value? Jenny afterthought – sent related note to TSC in context of “Akraino Portal Feature Project”
- Attendees
o Jim Einarsson, Jenny Koerv, Aaron Byrd, Andrew Wilkinson, Frank Zdarsky, Mike Hunter, Bill Zvonar
- Release Cadence
o we talked about proposing a cadence to the TSC
o currently, there’s talk of a second release in 6 months, but not of a cadence, per se
o we agreed to park this for later
- Proposed Changes from Last Process Sub-Committee Meeting
o we agreed to get those to vote at the TSC
o ACTION: Bill to get those on the agenda for the next TSC meeting
- More Proposed Changes
o Andrew asked about MVP re: Incubation – MVP as an “outcome” – doesn’t seem right
o instead, it should say something like During incubation, an MVP-quality product will be demonstrated (Alpha).
o discussion on Alpha/Beta/GA vs. Incubation/Mature/Core ensued
o we agreed on the following revised wording in section 3.3.4 (Project Lifecycle States and Reviews) of the TCD…
Project State | Description |
Proposal | Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs. |
Incubation | Project has resources, but is recognized to be in the early stages of development. In the Incubation state, the goal is to progress the project from Alpha (MVP) quality to Beta quality. |
Mature | Project is fully functioning and stable, has achieved successful releases. In the Mature state, the goal is to progress the project from Beta quality to GA quality. |
Core | Project provides value to and receives interest from a broad audience. In the Core state, the project is at GA quality – additional functionality may be added in subsequent releases. |
Archived | Project can reach Archived state for multiple reasons. Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical, etc.). Project in any state can be Archived through a Termination Review. In the Archived state, the project is Deprecated – no further bug fixes, security updates, etc. |
o ACTION: Bill to get this on the agenda for the next TSC meeting as well
- Checklists for Graduation
o further discussion on clarifying/simplifying the deliverables that should be delivered in each state, and the exit criteria for graduating from one state to another
o stuff like security checklists, and other things that might be specific to a given BP Family
o also should add language around release numbering – e.g. is “Mature” always Release 1? or Core?
o we agreed to start a table of such details
o ACTION: Bill to start the table of States, Deliverables, etc.