Difference between revisions of "Barbican/Integration"
< Barbican
Lisa Clark (talk | contribs) (→Barbican Integration) |
Lisa Clark (talk | contribs) (→Barbican Integration) |
||
| Line 1: | Line 1: | ||
=Barbican Integration= | =Barbican Integration= | ||
As we approach the end of the Juno cycle, the TC will be reviewing the maturity of Barbican for graduation to the Integrated release. Below are some requirements that need attention before the Integration Review. For a full list of requirements see http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst#n79 | As we approach the end of the Juno cycle, the TC will be reviewing the maturity of Barbican for graduation to the Integrated release. Below are some requirements that need attention before the Integration Review. For a full list of requirements see http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst#n79 | ||
| + | |||
| + | == Scope == | ||
| + | ===== (Status=MET) Project must not duplicate functionality present in other OpenStack projects, unless the project has intentionally done so with the intent of replacing it. ===== | ||
| + | ===== (Status=N/A) In the case that a project has intentionally duplicated functionality of another project, or portion of a project, the new project must reach a level of functionality and maturity such that we are ready to deprecate the old code and remove it after a well defined deprecation cycle. The deprecation plan agreed to by the PTLs of each affected project, including details for how users will be able to migrate from the old to the new, must be submitted to the TC for review as a part of the graduation review.===== | ||
== Maturity == | == Maturity == | ||
Revision as of 15:58, 18 August 2014
Contents
- 1 Barbican Integration
- 1.1 Scope
- 1.1.1 (Status=MET) Project must not duplicate functionality present in other OpenStack projects, unless the project has intentionally done so with the intent of replacing it.
- 1.1.2 (Status=N/A) In the case that a project has intentionally duplicated functionality of another project, or portion of a project, the new project must reach a level of functionality and maturity such that we are ready to deprecate the old code and remove it after a well defined deprecation cycle. The deprecation plan agreed to by the PTLs of each affected project, including details for how users will be able to migrate from the old to the new, must be submitted to the TC for review as a part of the graduation review.
- 1.2 Maturity
- 1.3 Process
- 1.3.1 (Status=MET) Project must have a diverse core reviewers team (more than 4 people)
- 1.3.2 (Status=MET) Core reviewers must enforce a minimum of 2 +2s before accepting a change
- 1.3.3 (Status=???) Project should have engaged with marketing team to check suitable official name
- 1.3.4 (Status=MET) Project must use OpenStack task, defect and design tracker(s)
- 1.4 QA
- 1.5 Documentation / User Support
- 1.6 Release Management / Security
- 1.1 Scope
Barbican Integration
As we approach the end of the Juno cycle, the TC will be reviewing the maturity of Barbican for graduation to the Integrated release. Below are some requirements that need attention before the Integration Review. For a full list of requirements see http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst#n79
Scope
(Status=MET) Project must not duplicate functionality present in other OpenStack projects, unless the project has intentionally done so with the intent of replacing it.
(Status=N/A) In the case that a project has intentionally duplicated functionality of another project, or portion of a project, the new project must reach a level of functionality and maturity such that we are ready to deprecate the old code and remove it after a well defined deprecation cycle. The deprecation plan agreed to by the PTLs of each affected project, including details for how users will be able to migrate from the old to the new, must be submitted to the TC for review as a part of the graduation review.
Maturity
(Status=MET) Project must have a large and diverse team of contributors
- Barbican contributors include developers from Rackspace, HP, Ericsson, Red Hat, Johns Hopkins University, A10 Networks, EMC, Blue Box.
(Status=???) 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)
- Integration with other projects including Dashboard
Process
(Status=MET) Project must have a diverse core reviewers team (more than 4 people)
- 16 total core reviewers as of Aug 2014, including developers from Rackspace, Red Hat, and Johns Hopkins University.
(Status=MET) Core reviewers must enforce a minimum of 2 +2s before accepting a change
- Core reviewers enforce a minimum of 2 +2s and require a different core reviewer to merge the change.
(Status=???) Project should have engaged with marketing team to check suitable official name
(Status=MET) Project must use OpenStack task, defect and design tracker(s)
- Task: https://launchpad.net/barbican
- Defect: https://bugs.launchpad.net/barbican
- Design: Blueprints are proposed via change requests to the barbican-specs repository and approvals are performed via gerrit. The implementation status of a blueprint can be found by reviewing the blueprint status in Launchpad
QA
- "Decent" unit and functional test coverage. - This is an area where we could use more work
Documentation / User Support
- End-user documentation
- API use
- CLI use
- Dashboard use
- Installation/Deployment
- User Support
- Proven history of support both in openstack@ mailing list and Ask OpenStack. - Note that we should confirm with TC whether QA in Launchpad meets this requirement, or if we should be focusing on ask.openstack.org. It seems the two sites are unrelated.
Release Management / Security
- Provide a 2+ person team that will handle the Barbican Vulnerability Process. See https://wiki.openstack.org/wiki/Vulnerability_Management for more information.
- Douglas Mendizabal (redrobot)
- (hyakuhei)
