Anuket Project

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Next »

CNTT Elbrus release planning (for reference)


Proposed milestones

Note:  this table is ONLY intended to identify criteria for the milestones (i.e., a checklist to determine whether the milestone has been reached).  It does not speak to how these items will be done, or when they will be initiated.  Those will be determined separately.

MilestoneDescriptionSoftware CriteriaSoftware ProcessesSpecification Criteria (adapted from Elbrus release)Specification ProcessesDeltaNotes
M0Start of releaseNone
None


M1Release Definition
  • Agreement on scope and versions
    • RC & RI effort scoped with owners identified
    • Cedric Ollivier : effort depends on the contributors and their activities. Does it mean that new contributors will first sign off before the release start?
    • RM & RA versions selected 
      • Note: RI version aligns with RA version (e.g., RI2 version number will be identical to the selected RA2 version)
      • Note:  the RA version selected will not be the same RA version that is currently in process with the specification team (N-1)
      • Cedric Ollivier : what do this two bullets mean? RI1 and RI2 are not aligned with RA1 versions (e.g. RI1 is deploying Stein and RA1 switched from Pike to Train) Does it force RI1 and RI2 to be aligned with latest stable RA versions?
      • Note:  RA specifies Openstack/Kubernetes
    • Prioritized features selected for implementation from specifications
    • Cedric Ollivier : Priorization is applied on the projects depending on the contributor interests. It can't be more than an release agreement as it was more or less in place in OPNFV
  • Project release plans submitted
    • Note: submission of a project release plan also serves as an intent-to-participate notification
  • Agreement on scope and versions
    • RI (Note:  aligned with RA version for which an RC exists, or which will be completed before RI)
      1. RI workstream lead (WSL) initiates community discussion with stakeholders (weekly technical discussion, email, etc.)
        1. RM and RA versions
        2. Features from RA selected for implementation
      2. Develop consensus
      3. RI WSL make recommendation to the TSC
      4. TSC votes


  • Project plans
    • Software projects will submit a project plan, following the template developed for OPNFV for the Jerma release.


  • Jira
    • Release manager creates common release name string for Jira
    • Cedric Ollivier : No need to create falsy JIRA tickets asking to create a stable branch. My 2 cents: JIRA should be more an interface with the end users (bug/feature request/etc.).


  • RC validation plan created or updated
    • RC lead(s) confirm validation plan ready


  • RI validation plan created and or updated
    • RI lead(s) confirm validation plan is ready
  • High level scope created

High Level Scope

  • Work stream leads complete template (see example from Elbrus planning)
  • Present to TSC
  • TSC approval

RC

  • If there is a new or updated RA, then we will need a new, or updated RC.  Note that this is NOT necessarily the same RC referenced by the RI under development in the current release cycle. It may be the same, if the plan is to complete an RC before development of the RI within the same release cycle (see M2). 
    • Affirmation from RC workstream lead that RC will be developed in the current release cycle.


  • GitHub
    • Release manager sets release name
    • Release manager sets milestone dates
M0+4w



Release schedule approved

(Release manager prepares schedule and presents to TSC for feedback and approval)

M2Scope Freeze
  • Initial RC(s) ready for RI implementation (not required if RI selected at M1 is pre-existing)
  • Jira issues assigned to release

RC Readiness 

JIRA issues

  • Release manager confirms that each participating project has assigned issues to the release using the "Fix Version" field in Jira
  • Software development review of PRs completed
  • High Level Issues created as per scope (including review and feedback by software team)

Software development review of specifications

  1. Developers review specifications being referenced for the current release cycle.
  2. Developers create issues in GitHub Issues for the GitHub project that represents the specific specification being reviewed.

High Level issues created in GitHub

  1. Issues appear on project dashboard
M0+14w
M3

Code: RC Validation Testing

Spec: Content Freeze

  • RC validation testing completed

Cedric Ollivier : The test frameworks part of RC are far ahead (e.g. Anuket RC Kali is about Functest Jerma/Train)

  • High priority Jira issues resolved
  • Preliminary documentation completed

RC validation testing

  • RC workstream lead confirms successful completion of validation test plan (Note: validation test plan is TBD)
    • Should be independent of RI

High priority Jira issues resolved

Cedric Ollivier : What about Jenkins ? Here is the live run about RC1 (OpenStack Train / OPNFV Jerma). JIRA is falsy here (release process vs true verification) https://build.opnfv.org/ci/view/functest/job/functest-jerma-daily/487/

  • Confirmed by release manager

Preliminary documentation

  • Confirmed by the DOCs team (Note: currently no DOCs team or integrated documentation)

RI development is completed

  • Confirmed by RI workstream lead(s)
  • Content created matching issues
    • Note:  this does NOT mean that the creation of issues will stop.  Issues will continue to be created as needed.

Content created  matching issues

  • Only scope covered by closed PRs is included in the release
  • Workstream leads present the closed PRs to the TSC 
    • RM, RA(s), RC(s), RI(s)
  • PRs are marked complete in the project dashboard
M0 + 18w
M4

Code: RI Validation Testing

Spec: Proofreading

  • RI validation testing completed

Cedric Ollivier is it about only about execution or successful?

  • High priority Jira issues resolved

RI validation testing completed

  • The lead for each RI presents the validation plan and results to the TSC and confirms that testing is completed.

Cedric Ollivier : What about Jenkins ? Here is the live run about RC1 (OpenStack Train / OPNFV Jerma). JIRA is falsy here (release process vs true verification) https://build.opnfv.org/ci/view/functest/job/functest-jerma-daily/487/

High priority Jira issues resolved

  • Confirmed by release manager
  • Proofreading: Validate content and make corrections
  • No new content after this point for this release

Proofreading

  • All issues in to do list (dashboard) should be completed or backlogged.
M0+22w
M5Release Readiness
  • Final documentation completed
  • RI cookbook completed
  • Remaining Jira issues assigned to the release closed or pushed to next release
  • Release artifacts prepared
  • Standalone project testing completed

Final documentation 

  • Track issue in Jira or equivalent

RI Cookbook 

  • Track issue in Jira or equivalent

Jira cleanup

Cedric Ollivier : a bug could remain open if tracked by release notes. No need to falsy close it or to change the criteria to please the release management process.

  • Verified by release manager

Release artifacts

  • Questions:
    • Link to individual docs in github, or just point to main repo?
    • Do we have any format requirements for software artifacts (container, RPMs, etc.)? 


  • Release content finalized
  • Creation and submission of marketing highlights
  • Finalize version numbering for RM, RA1, RA2
  • Traceability matrix

Traceability Matrix (RI=>RA, RC=>RA, RA=>RM)

  • Captured by current specification documentation processes
M0+25w

Marketing highlights page completed

M6Release
  • Release artifacts available for distribution 
  • Standalone project self-release completed

  • Release packaged (branched  in GitHub), specification documents presented in the ReadTheDocs format

M0+26w

Notes from release process discussion at weekly technical meeting (March 15, 2021):  Anuket Weekly Technical Discussions - 2021.03.15#Releasemilestones(M1)-Releaseplanning-

Schedule Proposal for June Release (compressed to 16 w)

MilestoneDateNotes
M0

 


M1

 


M2

 


M3

 


M4

 


M5

 


M6

 


Notes

Attendees:  David, Al, Jim, Trevor

  • Plan for set of milestones for software development, since we have agreed that specifications and software will use different cadences.
  • No labels