Difference between revisions of "Barbican/Integration"
< Barbican
(→(Status=MET) Project should have a proven history of providing user support (on the openstack@ mailing list and on Ask OpenStack)) |
Lisa Clark (talk | contribs) (→(Status=WIP) Project must have end-user docs such as API use, CLI use, Dashboard use) |
||
| Line 39: | Line 39: | ||
===== (Status=WIP) Project must have end-user docs such as API use, CLI use, Dashboard use===== | ===== (Status=WIP) Project must have end-user docs such as API use, CLI use, Dashboard use===== | ||
* End-user documentation | * End-user documentation | ||
| − | ** API use | + | ** API use - docs are in place but out of date with current changes. Review of API docs and getting these up to date is needed. |
| − | ** CLI use | + | ** CLI use - minimal set of CLI docs exist today. These need to be reviewed and built out. |
| − | ** Dashboard use | + | ** Dashboard use - Whether we need docs for use of dashboard depends on whether we are required to integrate with Horizon as a graduation requirement |
| − | ** When can we move Docbook documentation to openstack repos? | + | ** TC Question: When can we move Docbook documentation to openstack repos? |
===== (Status=WIP) Project should have installation docs providing install/deployment in an integrated manner similar to other OpenStack projects, including configuration reference information for all options===== | ===== (Status=WIP) Project should have installation docs providing install/deployment in an integrated manner similar to other OpenStack projects, including configuration reference information for all options===== | ||
Revision as of 17:14, 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.4.1 (Status=MET) 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.
- 1.4.2 (Status=WIP) Project must have decent unit test and functional tests coverage
- 1.4.3 (Status=MET) Project must be compatible with all currently OpenStack-supported versions of Python
- 1.4.4 (Status=???) Project should have a decent record of triaging incoming bugs
- 1.5 Documentation / User Support
- 1.5.1 (Status=WIP) Project must have end-user docs such as API use, CLI use, Dashboard use
- 1.5.2 (Status=WIP) Project should have installation docs providing install/deployment in an integrated manner similar to other OpenStack projects, including configuration reference information for all options
- 1.5.3 (Status=MET) Project should have a proven history of providing user support (on the openstack@ mailing list and on Ask OpenStack)
- 1.6 Release Management / Security
- 1.6.1 (Status=MET) Project must have followed at least two common milestones (follow the common cycle at least since X-2)
- 1.6.2 (Status=MET) Project must have had at least one of their milestones handled by the release management team (at least the X-3 milestone)
- 1.6.3 (Status=MET) Project must provide a 2+ person team that will handle the project specific vulnerability process [3]_
- 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)
- 11 total core reviewers as of Aug 2014, including developers from Rackspace, Red Hat, and Johns Hopkins University, and EMC.
(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
(Status=MET) 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.
(Status=WIP) Project must have decent unit test and functional tests coverage
- "Decent" unit and functional test coverage. - This is an area where we could use more work
(Status=MET) Project must be compatible with all currently OpenStack-supported versions of Python
Barbican gates changes against Python 2.6 and 2.7
(Status=???) Project should have a decent record of triaging incoming bugs
Documentation / User Support
(Status=WIP) Project must have end-user docs such as API use, CLI use, Dashboard use
- End-user documentation
- API use - docs are in place but out of date with current changes. Review of API docs and getting these up to date is needed.
- CLI use - minimal set of CLI docs exist today. These need to be reviewed and built out.
- Dashboard use - Whether we need docs for use of dashboard depends on whether we are required to integrate with Horizon as a graduation requirement
- TC Question: When can we move Docbook documentation to openstack repos?
(Status=WIP) Project should have installation docs providing install/deployment in an integrated manner similar to other OpenStack projects, including configuration reference information for all options
- Installation/Deployment
(Status=MET) Project should have a proven history of providing user support (on the openstack@ mailing list and on Ask OpenStack)
- User Support
- Proven history of support both in openstack@ mailing list and Ask OpenStack
- Barbican team is very responsive to Barbican questions in both openstack@lists.openstack.org and openstack-dev@lists.openstack.org
- Barbican team actively monitors ask.openstack.org for Barbican questions
- Question for TC: Is ask.openstack.org the official place for questions? Launchpad also has this feature, but it is currently turned off for Barbican.
- Proven history of support both in openstack@ mailing list and Ask OpenStack
Release Management / Security
(Status=MET) Project must have followed at least two common milestones (follow the common cycle at least since X-2)
Barbican has released Milestones alongside Openstack since Havana-1
(Status=MET) Project must have had at least one of their milestones handled by the release management team (at least the X-3 milestone)
Juno-2 was released by Openstack Release Management team
(Status=MET) Project must provide a 2+ person team that will handle the project specific vulnerability process [3]_
- Douglas Mendizabal (Rackspace)
- IRC: redrobot
- Robert Clark (HP)
- IRC: hyakuhei
- Douglas Mendizabal (Rackspace)
