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 <[email protected]> >> 150 jfwood <[email protected]> >> 65 Douglas Mendizabal <[email protected]> >> 39 Jarret Raim <[email protected]> >> 17 Malini K. Bhandaru <[email protected]> >> 10 Paul Kehrer <[email protected]> >> 10 Jenkins <[email protected]> >> 8 jqxin2006 <[email protected]> >> 7 Arash Ghoreyshi <[email protected]> >> 5 Chad Lung <[email protected]> >> 3 Dolph Mathews <[email protected]> >> 2 John Vrbanac <[email protected]> >> 1 Steven Gonzales <[email protected]> >> 1 Russell Bryant <[email protected]> >> 1 Bryan D. Payne <[email protected]> >> >> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
