Difference between revisions of "Manila/Graduation"

Revision as of 23:14, 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.	[[1]]
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...)	Completed recently.
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.	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	Action
Green	Project must have a basic devstack-gate job set up

Documentation / User support

Status	Action
Green	Project must have docs for developers who want to contribute to the project
Green	Project should have API documentation for devs who want to add to the API, updated when the code is updated

Legal requirements

Status	Action
Green	Project must be licensed under the Apache License v2
Green	Project must have no library dependencies which effectively restrict how the project may be distributed or deployed [1]
Green	All contributors to the project must have signed the CLA
Green	Project must have no known trademark issues [2]

 [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

@@ Line 5: / Line 5: @@
 ==== Scope ====
 {| border="1" cellpadding="4"
-! Status
+|-
-! Requirement
+! Status !! Requirement !! How Met
-ǃ How Met
+|-
-|-
 | <span style="background:green">Green</span>
 | 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>
@@ Line 19: / Line 18: @@
 | <span style="background:green">Green</span>
 | 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. 90
+| 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.
 |-
 | <span style="background:green">Green</span>
-|Project should leverage existing functionality in other OpenStack projects as much as possible
+| 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.
 |}
@@ Line 29: / Line 28: @@
 {| border="1" cellpadding="4"
-! Status
+|-
-! Action
+! Status !! Requirement !! How Met
 |-
 | <span style="background:yellow">Yellow</span>
 | Project should have an active team of contributors.
+| [[http://www.stackalytics.com/?release=all&metric=commits&project_type=stackforge&module=manila]]
 |-
 | <span style="background:green">Green</span>
 | 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.
 |-
 | <span style="background:green">Green</span>
 | 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.
 |}
@@ Line 45: / Line 47: @@
 {| border="1" cellpadding="4"
-! Status
+|-
-! Action
+! Status !! Requirement !! How Met
 |-
 | <span style="background:green">Green</span>
 | Project must be hosted under stackforge (and therefore use git as its VCS)
+| Moved to stackforge in 2013
 |-
 | <span style="background:yellow">Yellow</span>
 | Project must obey OpenStack coordinated project interface (such as tox, pbr, global-requirements...)
+| Completed recently.
 |-
 | <span style="background:green">Green</span>
 | Project should use oslo libraries or oslo-incubator where appropriate
+| True since the beginning thanks to fork from Cinder.
 |-
 | <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.
+| [[Manila/Program_Application]]
 |-
-| <span style="background:yellow">Yellow</span>
+| <span style="background:yellow">Green</span>
 | 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.
 |-
 | <span style="background:green">Green</span>
 | Reviews should follow the same criteria as OpenStack projects (2 +2s before +A)
+| We started enforcing this rule during Icehouse.
 |-
 | <span style="background:green">Green</span>
 | Project should use the official openstack lists for discussion
+| Manila uses openstack-dev exclusively for email discussions and appropriate freenode channels for chat/meetings.
 |}

Difference between revisions of "Manila/Graduation"

Revision as of 23:14, 13 June 2014

Contents

Incubation Requirements

Scope

Maturity

Process

QA

Documentation / User support

Legal requirements

Graduation (to integrated) Requirements

Scope

Maturity

Process

QA

Documentation / User support

Release management / Security