Open Stack

On 12/02/2013 04:12 PM, Jarret Raim wrote:
>>
>> 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

Awesome. Also, if you don't mind - we should add "testr" to that list.
We're looking at some things in infra that will need the subunit processing.

>>
>>>  ** 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 :)

Whatever gave you that idea? :)

>>>  ** 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
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>