Open Stack

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

In looking through the documentation for incubating [1], there doesn¹t
seem to be any mention of also having to be associated with a program. Is
it a requirement that all projects belong to a program at this point? If
so, I guess we would be asking for a new program as I think that
encryption and key management is a separate concern from the rest of the
programs listed here [2].

[1] https://wiki.openstack.org/wiki/Governance/NewProjects
[2] https://wiki.openstack.org/wiki/Programs


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

Happy to add this, I¹ll put it in the wiki today.

>> ** Team must have a mission statement
>
>This is missing.

We do have a mission statement on the Barbican/Incubation page here:
https://wiki.openstack.org/wiki/Barbican/Incubation


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

We¹re happy to do an election. Is this something we can do as part of the
next election cycle? Or something that needs to be done out of band?


>
>> ** Team should have a clear way to grant ATC (voting) status to its
>>    significant contributors
>
>Related to the above

I thought that the process of becoming an ATC was pretty well set [3]. Is
there some specific that Barbican would have to do that is different than
the ATC rules in the Tech Committee documentation?

[3] 
https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee


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

I will add a deliverables section, but you are correct.


>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

As mentioned above, I¹ll add this to the wiki today.

>
>>  ** 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.wood at rackspace.com>
>   150	jfwood <john.wood at rackspace.com>
>    65	Douglas Mendizabal <douglas.mendizabal at rackspace.com>
>    39	Jarret Raim <jarret.raim at rackspace.com>
>    17	Malini K. Bhandaru <malini.k.bhandaru at intel.com>
>    10	Paul Kehrer <paul.l.kehrer at gmail.com>
>    10	Jenkins <jenkins at review.openstack.org>
>     8	jqxin2006 <jqxin2006 at gmail.com>
>     7	Arash Ghoreyshi <arashghoreyshi at gmail.com>
>     5	Chad Lung <chad.lung at gmail.com>
>     3	Dolph Mathews <dolph.mathews at gmail.com>
>     2	John Vrbanac <john.vrbanac at rackspace.com>
>     1	Steven Gonzales <stevendgonzales at gmail.com>
>     1	Russell Bryant <rbryant at redhat.com>
>     1	Bryan D. Payne <bdpayne at 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.

There has been some interest from some quarters (RedHat, HP and others) in
additional support. I hope that the incubation process will help
accelerate external contributions.
>
>>  ** Project should not have a major architectural rewrite planned. API
>>should
>>     be reasonably stable.
>
>Thoughts from the Barbican team on this?

We plan to add additional functionality to the API, but the current API
should be reasonably stable. That being said, one major goal is to enable
encryption in various OpenStack services so we will change / add to the
API to meet the needs of consuming services. However, we will version the
API as needed.

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

Yep. That should be happening in the next few weeks (holidays are slowing
things down a bit).

>>  ** Project must obey OpenStack coordinated project interface (such as
>>tox,
>>     pbr, global-requirements...)
>
>Uses tox, but not pbr or global requirements

I added a ŒTasks¹ section for stuff we need to do from this review and
I¹ve added these tasks. [4]

[4] https://wiki.openstack.org/wiki/Barbican/Incubation

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

I¹ll address this in response to Monty¹s email since he seems highly
interested :)


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

As mentioned above, happy to change that.

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

<snip of review details>

>
>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/

Added to the tasks list on our incubation request.

>
>>  * 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-Interfa
>ce
>
>>  * 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.

All our people have signed the OpenStack CLA. What would be the best way
to provide this information? Date of signed CLA and date of first commits?

>
>>  ** 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_depen
>>dencies
>>  [2] https://wiki.openstack.org/wiki/LegalIssuesFAQ#New_Project_Names
>
>[3]
>http://lists.openstack.org/pipermail/openstack-dev/2013-December/020844.ht
>ml
>[4] https://review.openstack.org/59472
>
>-- 
>Russell Bryant



Thanks for all the feedback!

Jarret