Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Name

Affiliation

Email

LF ID

Tina TsouArmtina.tsou@arm.com
Tapio TallgrenNokiatapio.tallgren@nokia.com
Frank ZdarskyRed Hatfzdarsky@redhat.com
Jenny KoervInteljenny.koerv@intel.comJennifer Koerv
Deepak SInteldeepak.s@intel.com
Qasim ArhamJuniperqarham@juniper.net
Andrew WilkinsonEricssonandrew.wilkinson@ericsson.com
Sukhdev KapurJunipersukhdev@juniper.net
Wenjing ChuHuaweiwenjing.chu@huawei.com
Wenhui ZhangPenn Statewuz49@ist.psu.edu
Gerry WinsorNokiagerald.winsor@nokia.com
Kandan KathirvelAT&Tkk0563@att.com
Adnan SaleemRadisysadnan.saleem@radisys.com
Jim EinarssonWind Riverjim.einarsson@windriver.com
Jack LiuArmjack.liu@arm.com
Ryota IshibashiNTT

ryota.ishibashi.xy@hco.ntt.co.jp


Hiroshi YamamotoNTThiroshi.yamamoto.pz@hco.ntt.co.jp

Project Reviews

Meeting Content (minutes / recording / slides / other):

...

  1. TCD sections 3.3.7.1 and 3.3.4 discussed in 11/30 Process Sub-Committee and shared/agreed/implemented at TSC F2F 12/6-7 (summary/language recommendation here: 2018-11-30 Meeting notesRemove This Page 1). 
  2. Clean up/changes to TCD 3.3.8.1 and 3.3.2.3.1 language discussed/presented in TSC Meeting 1/10 (see minutes/slide 4 here Technical Steering Committee (TSC)).
  3. More specific language in Maturity Review 3.3.7.2.
  4. 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.
  5. Architecture has been reviewed by the Architecture Committee CI/CD Sub-Committee, TSC and presented to broader Akraino community?
  6. Project Contributors have provided a validation lab 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.
  7. Project is active and contributes to Akraino: The project demonstrates a stable or an increasing number of commits and/or contributions across recent releases measurable by TSC discretion. Contributions are commits which got that have been merged to a repository of an Akraino project repository or a related upstream project. Commit examples are can for example 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.
  8. 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.

...

November 30, 2018  minutes


Attendees:

Jim Einarsson, Windriver

Andrew Wilkinson, Ericsson

Jenny Koerv, Intel

Frank Zdarsky, Red Hat

Adnan Saleem, Radysis

 

The Process Sub-Committee is generally agreed that further discussion on BP submission, review and graduation methodology, clarification on Technical Doc language and better understanding of CI/CD environment and Flock lab requirements should be further discussed before scheduled BP reviews 12/6.  This is mainly for two broad reasons

  1. Further understanding of the CI/CD environment is critical to submit and review a blueprint as defined by the Technical Community Document (TCD)
  2. The TCD itself is confusing, redundant and insufficient as written to efficiently conduct and conclude a fair BP or project review process.

There are currently three places in the technical document where criteria and/or methodology relevant to the F2F BP review process are defined:

3.3.2.2 Akraino Edge Stack Integration Projects (Blueprints)

3.3.4  Project Lifecycle States and Reviews

3.3.7.1 Incubation Review

 

The Process Sub-Committee would like to propose revising the following language in the TCD 3.3.2.2 Blueprint section (which should not require such detail for the Incubation Review state outlined in 3.3.4—and is currently impossible to speak to at this review cycle without an agreed and operating CI/CD foundation):

Current TCD language (strikes represent the language we would like revised):

The requestor should demonstrate the following aspects to the TSC:

  1. Each initial blueprint is encouraged to take on at least two Committers from different companies
  2. Complete all templates outlined in this document
  3. 3.       A lab with exact configuration required by the blueprint to connect with Akraino CI and demonstrate CD. User should demonstrate either an existing lab or the funding and commitment to build the needed configuration.
  4. 4.       Blueprint is aligned with the Akriano Edge Stack Charter
  5. Blueprint code that will be developed and used with Akraino repository should use only Open Source software components either from upstream or Akriano projects.
  6. For new blueprints submission, the submitter should review existing blueprints and ensure it is not a duplicate blueprint and explain how the submission differs. The functional fit of an existing blueprint for a use case does not prevent an additional blueprint being submitted.

Process Sub-Committee proposed language:

The requestor should demonstrate the following aspects to the TSC:

  1. Each initial blueprint is encouraged to take on at least two Committers from different companies
  2. Complete all templates outlined in this document
  3. Prepared to commit lab resources to support collaborative development and validation testing
  4. Blueprint is aligned with the Akraino Edge Stack Charter and Technical Community Document
  5. Blueprint code that will be developed and used with Akraino repository should use only Open Source software components either from upstream or Akriano projects.
  6. For new blueprints submission, the submitter should review existing blueprints and ensure it is not a duplicate blueprint and explain how the submission differs. The functional fit of an existing blueprint for a use case does not prevent an additional blueprint being submitted


The Process Sub-Committee are agreed on the minimum criteria defined by the Proposal -> Incubation “State” (Section 3.3.4), and intend to use this language as our guide for the BP Incubation Reviews, and Incubation graduation recommendation:

Proposal State Criteria:

Project doesn’t really exist yet

May not have real resources

Is proposed and is expected to be created due to business needs (documented) 

Incubation State Criteria (paraphrased with explanation):

-Project has resources (commitment needed for Incubation Review, specifics not necessary at this time)

-Project in early stages of development (commitment needed, too preliminary for HW detail, Committer bios, exact tooling w/o CI/CD environment foundation and clarity)   

-Outcome of Incubation state is MVP (goals are demonstrating project value and gathering feedback);

-Not for production deployment (understood and agreed for Incubation State deliverable)


The Process Sub-Committee are not comfortable with the current language in 3.7.7.1 and find it too progressive and inconsistent with the above Incubation State description and targeted outcome.  We would like to propose revising the criteria identified under the 3.7.7.1 section of the TCD as follows:

Current TCD language (strikes represent the language we would like revised):

 Artifacts expected for Incubation Review:

Name of the project is appropriate (no trademark issues etc.);

Proposed repository name is all lower-case without any special characters

Project contact name, company and email are defined and documented
Description of the project goal and its purpose are defined
Scope and project plan are well defined
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
Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects, 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)

 

Process Sub-Committee proposed language:

 Artifacts expected for Incubation Review:

Name of the project is appropriate (no trademark issues etc.)

Proposed repository name is all lower-case without any special characters
Project contact name, company and email are defined and documented
Description of the project goal and its purpose are defined
Scope and project plan are well defined
Prepared to commit resources to each proposed blueprint species.
Contributors identified
Meets Akraino TSC Policies

Cross Project Dependencies (XPD) identified with upstream.


Other notes and recommendations:

  1. CI/CD discussion slated for Day 2 of Akraino TSC F2F next week should happen Day 1, and prior to BP reviews .
    1. Primary concerns are around not knowing what the CI environment will look like to plan tooling
    2. The CD environment being closed/behind firewall make it hard to collaboratively develop, test and troubleshoot for the agreed Contributors and community.
  2. We are not sure that a TSC vote should determine BP or project graduation from Phase to Phase to GA to EOL, etc.  Would like the TSC to consider whether meeting a certain set of validated criteria are met (Conformance model?) should be voted on rather than the TSC voting on moving a particular BP forward itself.
  3. The Project and Project lifecycle (~3.4) sections of the TCD should probably precede the BP section (3.3.2.2) since a BP is an Integration Project.
  4. We need an agreed/documented way to prioritize the BPs for review/evaluation (Date?  Maturity? # Contibutors?)
  5. We need an agreed/documented way to provide feedback to BP or project submitters after Reviews and an agreed and allotted amount of time to give Submitters to address gaps for a follow on submission.  Not really fair to vote on these right after review and not give the Submitters/Contributors time to correct/resubmit.
  6. Need clearer language in TCD around what “Launch” actually means and where to apply it within the document/State process.
  7. Need more refined language/plan from Upstream Sub-Committee around process/interface for project dependency socialization and integration.
  8. Need pointer to Akraino branded templates (slides?) from Jackie/LF.

 

AR – Jenny to provide spreadsheet Incubation Review cheat sheet to Process Sub-Committee for feedback/revision

AR – Jenny to provide first pass notes

AR- Frank, Andrew, Adnan to add anything I missed/got wrong to notes

AR—Jim to socialize/represent and summarize concerns/recommendations to broader TSC and TSC Chairs

December 6, 2018 TSC Meeting Blueprint Review:

...