Jump to: navigation, search

Manila/Graduation

< Manila
Revision as of 20:10, 4 June 2014 by Robert Esker (talk | contribs) (Scope)

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 Action
Green Project must have a clear and defined scope.
Green Project's scope should represent a measured progression for OpenStack as a whole.
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.
Green Project should leverage existing functionality in other OpenStack projects as much as possible

Maturity

Status Action
Yellow Project should have an active team of contributors.
Green Project should not have a major architectural rewrite planned
Green Project APIs should be reasonably stable.

Process

Status Action
Green Project must be hosted under stackforge (and therefore use git as its VCS)
Yellow Project must obey OpenStack coordinated project interface (such as tox, pbr, global-requirements...)
Green Project should use oslo libraries or oslo-incubator where appropriate
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.
Yellow Project must have a well-defined core review team, with reviews distributed amongst the team (and not being primarily done by one person)
Green Reviews should follow the same criteria as OpenStack projects (2 +2s before +A)
Green Project should use the official openstack lists for discussion

QA

Status Action
Yellow Project must have a basic devstack-gate job set up

Documentation / User support

Status Action
Yellow Project must have docs for developers who want to contribute to the project
Red 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