Page tree
Skip to end of metadata
Go to start of metadata

OPNFV Project Lifecycle:


  • Today, all of the approved projects in OPNFV are in the Incubation Stage
  • According to the criteria outlined on the Project Lifecycle document above, a number of projects would be eligible for a Graduation Review
    • e.g. Functest, Releng, several installer projects, etc.


  • Questions from the community (new after the March 7th TSC meeting)
    • What are the benefits of being a Mature project?
      • Is it more of a badge of honor/bragging rights? 
    • Will there be different expectations from Mature projects?
      • e.g. Mature project team members are expected to act as "mentors" to other community members 
    • Is there a need for an Integration Review (or projects in "Integration" state)?
      • The consensus seems to be that this is no longer necessary/relevant
    • For graduation review, does it make sense to add one of the criteria for "Contributor Diversity" from the Integration 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 2 releases, which means they were reviewing contributions to the project in OPNFV Gerrit and/or in the review-tool of the target upstream project(s)." 
    • Should adding value to other projects and community members be another criteria for Graduation Review?
      • How can this me measured?
    • Do we also need to start discussing "Core" projects in OPNFV?  For example, will we stop/postpone the release if certain core projects are not ready?
    • Consider TSC seats for Mature project PTLs?


  • A possible process for Graduation Review
    1. Periodic (e.g. annual) community nomination
    2. Project team either accepts/declines the nomination
    3. If the project team accepts the nomination, the team writes up a justification
    4. TSC vote



  • No labels


  1. Graduation reviews are a good vehicle to give people who are not so familar with OPNFV projects an understanding of how "mature" projects are, with "maturity" reflecting the merit the project created for the overall community and industry.
    As such, I would strongly suggest to not provide for any further labeling or classification for projects which isn't merit focused, i.e. classifying projects into core and context categories will create artificial boundaries for projects and would thus cause more harm then good.

  2. I think we need to revisit the expectations 2.5 years into OPNFV. IMO, in a rapidly evolving industry, projects will come and go, morph and merge, both in OPNFV and upstream. In fact, if we walk the "working upstream" talk, projects in OPNFV really should be quite short-lived (a couple of releases) before they are upstreamed fully, leaving behind only perhaps some deployment/test scripts as needed for the OPNFV CI/CD system, and some documents which describe what the project was about and where further development of it lives. Exceptions to this expectation for "succeed and disappear" may be the truly integration-focused projects (e.g. OpenStack distro-centered installers) and test projects that span upstream projects. 

  3. Bryan Sullivan, as you also noted the point is that there are a number of projects in OPNFV focused on infrastructure, integration, testing etc.  Can all "feature" projects be upstreamed?

  4. Ray Paik that depends upon what you call a feature project, and what they intend to do. It's my belief that all feature projects should have the intent to further develop upstream project features. So all such projects should eventually be upstreamed, and if needed transition or sunset into ongoing installer/test support. Some groups like the MANO group and some projects like the Models project operate at a different level, promoting development of solutions (or convergence of them) in their space but not developing specific platform code in OPNFV, and may continue on as projects though they will not deliver code into the OPNFV platform - rather tests/utilities, installer support, etc. 

  5. This appears to be a philosophical merry go round. And I am in agreement with what Frank Brockners has said, above. I think the context of a graduation review still makes very little, if any, sense outside of the scope of an architecture. We need to drive what is our OPNFV Architecture and Roadmap. Just because another community has a notion of a lifecycle is rather irrelevant given that they are likely to be focused on a narrower scope and aren't likely taking into account how they can converge with their next closest competitor. If we have, at least an architecture, we can then begin looking at what the abstractions are for handling the "2 or more" discussion. And when a project meets those requirements, then I can see it being qualified for graduation. I think we've lost a bit of this urgency, since we first started OPNFV. 
    As for the concept of mature projects helping newer projects in the community, I like the concept, but disagree with the framing. Projects don't help other projects. People help. PTLs will in fact come and go and take on different roles in our community. This should be encouraged. But this characteristic truly rests upon our individual community members, and not even upon the companies that are represented by said people. 

    In order to better facilitate this, I have recommended, and will continue to recommend, that we adopt a Working Groups model to ensure we have coverage of all of the major functional blocks of a high level architecture. It will give us better focus, as we divvy up the work on this. But this needs to come from the TSC. And I am hoping to see some leadership on this. Frankly, I was expecting us to be a bit further along than where we are.