On 12/02/2013 10:19 AM, Jarret Raim wrote:
> All,
>
> Barbican is the OpenStack key management service and we’d like to
> request incubation for the Icehouse release. A Rackspace sponsored team
> has been working for about 9 months now, including following the Havana
> release cycle for our first release.
>
> Our incubation request is here:
> https://wiki.openstack.org/wiki/Barbican
>
> Our documentation is mostly hosted at GitHub for the moment, though we
> are in the process of converting much of it to DocBook.
> https://github.com/cloudkeep/barbican
> https://github.com/cloudkeep/barbican/wiki
>
>
> The Barbican team will be on IRC today at #openstack-barbican and you
> can contact us using the barbi...@lists.rackspace.com mailing list if
> desired.
The TC is currently working on formalizing requirements for new programs
and projects [3]. I figured I would give them a try against this
application.
First, I'm assuming that the application is for a new program that
contains the new project. The application doesn't make that bit clear,
though.
> Teams in OpenStack can be created as-needed and grow organically. As the team
> work matures, some technical efforts will be recognized as essential to the
> completion of the OpenStack project mission. By becoming an official Program,
> they place themselves under the authority of the OpenStack Technical
> Committee. In return, their contributors get to vote in the Technical
> Committee election, and they get some space and time to discuss future
> development at our Design Summits. When considering new programs, the TC will
> look into a number of criteria, including (but not limited to):
> * Scope
> ** Team must have a specific scope, separated from others teams scope
I would like to see a statement of scope for Barbican on the
application. It should specifically cover how the scope differs from
other programs, in particular the Identity program.
> ** Team must have a mission statement
This is missing.
> * Maturity
> ** Team must already exist, have regular meetings and produce some work
This seems covered.
> ** Team should have a lead, elected by the team contributors
Was the PTL elected? I can't seem to find record of that. If not, I
would like to see an election held for the PTL.
> ** Team should have a clear way to grant ATC (voting) status to its
> significant contributors
Related to the above
> * Deliverables
> ** Team should have a number of clear deliverables
barbican and python-barbicanclient, I presume. It would be nice to have
this clearly defined on the application.
Now, for the project specific requirements:
> Projects wishing to be included in the integrated release of OpenStack must
> first apply for incubation status. During their incubation period, they will
> be able to access new resources and tap into other OpenStack programs (in
> particular the Documentation, QA, Infrastructure and Release management
> teams)
> to learn about the OpenStack processes and get assistance in their
> integration
> efforts.
>
> The TC will evaluate the project scope and its complementarity with existing
> integrated projects and other official programs, look into the project
> technical choices, and check a number of requirements, including (but not
> limited to):
>
> * Scope
> ** Project must have a clear and defined scope
This is missing
> ** 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.
> ** Project should leverage existing functionality in other OpenStack projects
> as much as possible
I'm going to hold off on diving into this too far until the scope is
clarified.
> * Maturity
> ** Project should have a diverse and active team of contributors
Using a mailmap file [4]:
$ git shortlog -s -e | sort -n -r
172 John Wood <john.w...@rackspace.com>
150 jfwood <john.w...@rackspace.com>
65 Douglas Mendizabal <douglas.mendiza...@rackspace.com>
39 Jarret Raim <jarret.r...@rackspace.com>
17 Malini K. Bhandaru <malini.k.bhand...@intel.com>
10 Paul Kehrer <paul.l.keh...@gmail.com>
10 Jenkins <jenk...@review.openstack.org>
8 jqxin2006 <jqxin2...@gmail.com>
7 Arash Ghoreyshi <arashghorey...@gmail.com>
5 Chad Lung <chad.l...@gmail.com>
3 Dolph Mathews <dolph.math...@gmail.com>
2 John Vrbanac <john.vrba...@rackspace.com>
1 Steven Gonzales <stevendgonza...@gmail.com>
1 Russell Bryant <rbry...@redhat.com>
1 Bryan D. Payne <bdpa...@acm.org>
It appears to be an effort done by a group, and not an individual. Most
commits by far are from Rackspace, but there is at least one non-trivial
contributor (Malini) from another company (Intel), so I think this is OK.
> ** Project should not have a major architectural rewrite planned. API should
> be reasonably stable.
Thoughts from the Barbican team on this?
>
> * Process
> ** Project must be hosted under stackforge (and therefore use git as its VCS)
I see that barbican is now on stackforge, but python-barbicanclient is
still on github. Is that being moved soon?
> ** Project must obey OpenStack coordinated project interface (such as tox,
> pbr, global-requirements...)
Uses tox, but not pbr or global requirements
> ** Project should use oslo libraries or oslo-incubator where appropriate
The list looks reasonable right now. Barbican should put migrating to
oslo.messaging on the Icehouse roadmap though.
context.py
eventlet_backdoor.py
fileutils.py
importutils.py
jsonutils.py
log.py
network_utils.py
policy.py
rpc
sslutils.py
timeutils.py
crypto
excutils.py
gettextutils.py
local.py
loopingcall.py
notifier
processutils.py
service.py
threadgroup.py
uuidutils.py
> ** Project must have a PTL elected by its contributors (with same rules as
> the
> OpenStack PTL elections)
I see a PTL, but AFAICT, it was not done by election.
> ** Project must have a well-defined core review team, with reviews
> distributed
> amongst the team (and not being primarily done by one person)
barbican-core: https://review.openstack.org/#/admin/groups/178,members
There seems to be healthy review culture of not relying on one person to
do most of the reviews.
Reviews for the last 180 days in barbican
** -- barbican-core team member
+-------------------+---------------------------------------+----------------+
| Reviewer | Reviews -2 -1 +1 +2 +A +/- % |
Disagreements* |
+-------------------+---------------------------------------+----------------+
| dougmendizabal ** | 46 0 8 9 29 27 82.6% | 3 (
6.5%) |
| woodster ** | 40 1 8 6 25 30 77.5% | 0 (
0.0%) |
| reaperhulk ** | 28 0 2 5 21 22 92.9% | 1 (
3.6%) |
| john.vrbanac ** | 5 0 0 5 0 0 100.0% | 1 (
20.0%) |
| arvind-tiwari | 4 0 3 1 0 0 25.0% | 0 (
0.0%) |
| dolph | 1 0 0 1 0 0 100.0% | 0 (
0.0%) |
| mordred | 1 0 1 0 0 0 0.0% | 0 (
0.0%) |
| vichoward | 1 0 0 1 0 0 100.0% | 0 (
0.0%) |
| arash | 0 0 0 0 0 0 0.0% | 0 (
0.0%) |
| bdpayne | 0 0 0 0 0 0 0.0% | 0 (
0.0%) |
| saschpe | 0 0 0 0 0 0 0.0% | 0 (
0.0%) |
+-------------------+---------------------------------------+----------------+
Total reviews: 126 (0.7/day)
Total reviewers: 8 (avg 0.1 reviews/day)
Total reviews by core team: 119 (0.7/day)
Core team size: 4 (avg 0.2 reviews/day)
New patch sets in the last 180 days: 142 (0.8/day)
Changes involved in the last 180 days: 73 (0.4/day)
New changes in the last 180 days: 73 (0.4/day)
Changes merged in the last 180 days: 67 (0.4/day)
Changes abandoned in the last 180 days: 3 (0.0/day)
Changes left in state WIP in the last 180 days: 1 (0.0/day)
Queue growth in the last 180 days: 2 (0.0/day)
Average number of patches per changeset: 1.9
(*) Disagreements are defined as a +1 or +2 vote on a patch where a core
team member later gave a -1 or -2 vote, or a negative vote overridden
with a positive one afterwards.
> ** Reviews should follow the same criteria as OpenStack projects (2 +2s
> before +A)
Seems to be the case:
https://review.openstack.org/#/q/project:stackforge/barbican,n,z
> * QA
> ** Project must have a basic devstack-gate job set up
This is not in place yet. Here is an example of how I did it for
another stackforge project:
https://review.openstack.org/#/c/57098/
> * Documentation / User support
> ** Project must have docs for developers who want to contribute to the
> project
https://github.com/cloudkeep/barbican/wiki/Gerrit-Review-Process
> ** Project should have API documentation for devs who want to add to the API,
> updated when the code is updated
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
> * Legal requirements
> ** Project must be licensed under the Apache License v2
http://git.openstack.org/cgit/stackforge/barbican/tree/LICENSE
> ** Project must have no library dependencies which effectively restrict how
> the project may be distributed [1]
http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires
It looks like the only item here not in the global requirements is
Celery, which is licensed under a 3-clause BSD license.
https://github.com/celery/celery/blob/master/LICENSE
A notable point is this clause:
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
I'm not sure if we have other dependencies using this license already.
It's also not clear how to interpret this when Python is always
distributed as source. We can take this up on the legal-discuss mailing
list.
> ** All contributors to the project must have signed the CLA
Enforced by the use of gerrit with barbican. It will have to be
verified for contributions that went in before using gerrit, though.
This also needs to be checked for barbicanclient since they're not using
gerrit yet.
> ** Project must have no known trademark issues [2]
If we make it this far, we will handle this with foundation marketing.
> [1]
> https://wiki.openstack.org/wiki/LegalIssuesFAQ#Licensing_of_library_dependencies
> [2] https://wiki.openstack.org/wiki/LegalIssuesFAQ#New_Project_Names
[3]
http://lists.openstack.org/pipermail/openstack-dev/2013-December/020844.html
[4] https://review.openstack.org/59472
--
Russell Bryant
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
