Jump to: navigation, search

Difference between revisions of "Manila/Graduation"

(Process)
(Incubation Requirements)
Line 10: Line 10:
 
| <span style="background:green">Green</span>
 
| <span style="background:green">Green</span>
 
| Project must have a clear and defined scope.
 
| Project must have a clear and defined scope.
| See [[Manila/Incubation_Application]], [[Manila/Program_Application]]
+
| See [[Manila/Incubation_Application]], [[Manila/Program_Application]].
 
|-
 
|-
 
| <span style="background:green">Green</span>
 
| <span style="background:green">Green</span>
Line 52: Line 52:
 
| <span style="background:green">Green</span>
 
| <span style="background:green">Green</span>
 
| Project must be hosted under stackforge (and therefore use git as its VCS)
 
| Project must be hosted under stackforge (and therefore use git as its VCS)
| Moved to stackforge in 2013
+
| Moved to stackforge in 2013.
 
|-
 
|-
 
| <span style="background:yellow">Yellow</span>
 
| <span style="background:yellow">Yellow</span>
Line 64: Line 64:
 
| <span style="background:green">Green</span>
 
| <span style="background:green">Green</span>
 
| If project is not part of an existing program, it needs to file for a new program concurrently with the Incubation request, and fill the corresponding requirements.
 
| If project is not part of an existing program, it needs to file for a new program concurrently with the Incubation request, and fill the corresponding requirements.
| [[Manila/Program_Application]]
+
| See [[Manila/Program_Application]].
 
|-
 
|-
 
| <span style="background:green">Green</span>
 
| <span style="background:green">Green</span>
Line 94: Line 94:
 
! Status !! Requirement !! How Met
 
! Status !! Requirement !! How Met
 
|-
 
|-
| <span style="background:green">Green</span>
+
| <span style="background:yellow">Yellow</span>
 
| Project must have docs for developers who want to contribute to the project
 
| Project must have docs for developers who want to contribute to the project
| Links needed
+
| Links neededǃ
 
|-
 
|-
| <span style="background:green">Green</span>
+
| <span style="background:yellow">Yellow</span>
 
| Project should have API documentation for devs who want to add to the API, updated when the code is updated
 
| Project should have API documentation for devs who want to add to the API, updated when the code is updated
| Links needed
+
| Links neededǃ
 
|}
 
|}
  
Line 114: Line 114:
 
| <span style="background:green">Green</span>
 
| <span style="background:green">Green</span>
 
| Project must have no library dependencies which effectively restrict how the project may be distributed or deployed [1]
 
| Project must have no library dependencies which effectively restrict how the project may be distributed or deployed [1]
| This is true
+
| This is true.
 
|-
 
|-
 
| <span style="background:green">Green</span>
 
| <span style="background:green">Green</span>

Revision as of 23:34, 13 June 2014

Per the [Technical Committee's Incubation & Graduation Guidelines] this page is intended to track Manila's progress towards official incubation, subsequent graduation, and submission for inclusion as core:

Incubation Requirements

Scope

Status Requirement How Met
Green Project must have a clear and defined scope. See Manila/Incubation_Application, Manila/Program_Application.
Green Project's scope should represent a measured progression for OpenStack as a whole. Management of shared filesystems is a critical gap within OpenStack as well as most other cloud platforms.
Green Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication. Manila does not duplicate funcitonality of any other project, with the exception of Cinder, which it is a fork of. All of the block-specific functionality that was in Cinder has been removed and the only remaining duplicated code is parts of the LVM driver, which is deprecated and will be removed soon.
Green Project should leverage existing functionality in other OpenStack projects as much as possible Manila leverages Oslo for many of the things Cinder used Oslo for. Manila also leverages Cinder and Nova within its generic driver, and integration with Neutron is key to Manila's core functionality.

Maturity

Status Requirement How Met
Yellow Project should have an active team of contributors. Stackanalytics indicates that the team is highly active and becoming more diverse over time.
Green Project should not have a major architectural rewrite planned A major change to the architecture was made during the Icehouse timeframe and we now feel we can support all of the new features we have planned within the current architecture.
Green Project APIs should be reasonably stable. The vast majority of APIs have been stable since they were added, and since Icehouse the API has not required any disruptive changes. All new features can be implemented as new APIs or backwards-compatible extensions to existing APIs.

Process

Status Requirement How Met
Green Project must be hosted under stackforge (and therefore use git as its VCS) Moved to stackforge in 2013.
Yellow Project must obey OpenStack coordinated project interface (such as tox, pbr, global-requirements...) Believe this is complete, need to verify.
Green Project should use oslo libraries or oslo-incubator where appropriate True since the beginning thanks to fork from Cinder.
Green If project is not part of an existing program, it needs to file for a new program concurrently with the Incubation request, and fill the corresponding requirements. See Manila/Program_Application.
Green Project must have a well-defined core review team, with reviews distributed amongst the team (and not being primarily done by one person) Core team is well defined (currently 4 people). Reviews are spread around within the members we have. We are actively growing the core team to help spread the load.
Green Reviews should follow the same criteria as OpenStack projects (2 +2s before +A) We started enforcing this rule during Icehouse.
Green Project should use the official openstack lists for discussion Manila uses openstack-dev exclusively for email discussions and appropriate freenode channels for chat/meetings.

QA

Status Requirement How Met
Green Project must have a basic devstack-gate job set up Manila has gate tests using tempest+devstack.

Documentation / User support

Status Requirement How Met
Yellow Project must have docs for developers who want to contribute to the project Links neededǃ
Yellow Project should have API documentation for devs who want to add to the API, updated when the code is updated Links neededǃ

Legal requirements

Status Requirement How Met
Green Project must be licensed under the Apache License v2 True from the beginning.
Green Project must have no library dependencies which effectively restrict how the project may be distributed or deployed [1] This is true.
Green All contributors to the project must have signed the CLA This requirement enforced by gerrit.
Green Project must have no known trademark issues [2] A trademark search by NetApp legal turned up no issues.


 [1] https://wiki.openstack.org/wiki/LegalIssuesFAQ#Licensing_of_library_dependencies
 [2] https://wiki.openstack.org/wiki/LegalIssuesFAQ#New_Project_Names

Graduation (to integrated) Requirements

At the end of every cycle, incubated projects go through a graduation review to check if they are ready to be made an integral part of the next development cycle and be included in the next OpenStack integrated release. The TC will evaluate the technical maturity of the project and check a number of requirements, including (but not limited to):

Scope

Status Action
Project must not duplicate functionality present in other OpenStack projects

Maturity

Status Action
Project must have a large and diverse team of contributors
Project must have completed integration work with other integrated projects, as communicated by the TC when accepted into incubation (that includes Dashboard integration if applicable)

Process

Status Action
Project must have a diverse core reviewers team (more than 4 people)
Core reviewers must enforce a minimum of 2 +2s before accepting a change
Project should have engaged with marketing team to check suitable official name
Project must use OpenStack task, defect and design tracker(s)

QA

Status Action
Project must have a devstack-gate job running. This gate job should install the project using devstack and then run tempest tests. This job should run and vote in the check and gate pipelines for the project. It is *not* required that this job is running for the projects it depends on. This demonstrates that it would be easy to add the project to the integrated gate after graduation.
Project must have decent unit test and functional tests coverage
Project must be compatible with all currently OpenStack-supported versions of Python
Project should have a decent record of triaging incoming bugs

Documentation / User support

Status Action
Project must have end-user docs such as API use, CLI use, Dashboard use
Project should have installation docs providing install/deployment in an integrated manner similar to other OpenStack projects, including configuration reference information for all options
Project should have a proven history of providing user support (on the openstack@ mailing list and on Ask OpenStack)

Release management / Security

Status Action
Project must have followed at least two common milestones (follow the common cycle at least since X-2)
Project must have had at least one of their milestones handled by the release management team (at least the X-3 milestone)
Project must provide a 2+ person team that will handle the project specific vulnerability process [3]


 [3] https://wiki.openstack.org/wiki/Vulnerability_Management