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 you'll find the team's evaluation of the requirements documented in the governance docs found at 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)
 * Currently integrating with Neutron/LBaaS
 * Is Dashboard integration required for Graduation or is this something to address during Integrated cycle?

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. IOW Change Requests require approval from 3 core devs.


 * (Status=???) Project should have engaged with marketing team to check suitable official name
 * During review for incubation, a review of all entities that used the name "Barbican" include a UAE company that produces a non-alcoholic malt beverage called "Barbican", and a London radio station of the same 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


 * https://github.com/openstack/barbican-specs


 * http://blueprints.launchpad.net/barbican

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.
 * Barbican runs dsvm for both gate and check


 * (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

Barbican gates test changes against Python 2.6 and 2.7
 * (Status=MET) Project must be compatible with all currently OpenStack-supported versions of Python


 * (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.

Release Management / Security
Barbican has released Milestones alongside Openstack since Havana-1
 * (Status=MET) Project must have followed at least two common milestones (follow the common cycle at least since X-2)

Juno-2 was released by Openstack Release Management team
 * (Status=MET) Project must have had at least one of their milestones handled by the release management team (at least the X-3 milestone)


 * (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