REC Maturity review in Process Sub Committee

Andrew Wilkinson

Hello all Process SC members and Paul (Paul Carver PTL REC) and cc Akraino TSC co-chairs


I’m excited to invite you to join me to conduct Akraino’s very first blueprint Maturity review for the REC BP as requested by Paul Carver (the BP’s PTL).



As part of the TSC’s Maturity review process the Process SC coordinates the Documentation, Security, Functional and all other requirement reviews and provides a single recommendation to the TSC for consideration in their final voting on whether to graduate the BP from the Incubation to Mature status.


At the end of the process the Process SC will provide a simple ‘Approve’ or ‘Reject’ recommendation to the TSC with a documented rationale for each of the Maturity requirements that have been set by the TSC.


Please see the diagram below for a summary of the process. The Process SC will review based only on the criteria defined in the Process SC graduation review process page as approved by the TSC for Maturity. ( ). The agenda items in bold below are taken directly from these requirements – some items are trivial but I’d like to cover them all explicitly so there can be no doubt when it ultimately comes to the final TSC vote.



I am proposing to have two Process SC reviews (1) Tuesday 12th November at the standard Process SC timeslot and (2) Thursday 20th November (the second slot is a an additional slot). Paul if these do not work for you or a anyone you would like to be on the review from the project please let me know.



On the first call I’d like the PTL to:


  1. Introduce the BP (basic 5 minute overview so all are on the same page)


  1. Validation lab check

Note: There are two independent sets of logs as it is required to deploy the same BP on two validation labs for Maturity

Note: This may take up to 30 minutes.

  1. Release inclusion check
    1. Confirm the BP has been present in the minimum number of Akraino release cycles required for Maturity (i.e. 2)
  2. SW quality/functional check
    1. Prove the BP has passed the Validation Framework test requirements by reference to the Validation Framework GUI
    2. Request exemptions for any test cases in the Validation Framework which you consider either not valid or failing for any reason not caused by the BP per se
    3. Provide the pass/failure details of any additional test cases (if the BP defined any)
    4. The minimum security requirements will not be covered in this review but will rather be covered by the Security SC’s own review
  3. HW definition check
    1. In the BP’s release documentation show the exact HW being used on which the logs presented above apply to   
  4. Upstream dependencies check
    1. In the BP’s release documentation show the full set of upstream dependencies are defined   
  5. Documentation check
    1. The documentation requirements will not be covered in this review but will rather be covered by the Documentations SC’s own review
  6. Community Health and Stability check
    1. The PTL should provide a summary of contributors and committers and companies and demonstrate growth
    2. The PTL should demonstrate stable output (code base, documents) within its history of releases



On the second call I would ask the Documentation and Security SCs to have their recommendations ready (Approve or Reject) so that we can incorporate them into the Process SC’s formal recommendation to the TSC for voting. I leave the scheduling and conducting of the Documentation and Security review to those SCs in separate meetings (we won’t cover the details of documentation and security requirement checks in the two Process SC meetings).


One the second call we would also review any changes that may have been requested at the first Process SC review – that way there should be plenty of time to enable a positive recommendation to the TSC.


@Paul Carver please feel free to reach out to me if you like to discuss.








Join to automatically receive all group messages.