Open Stack

Hello TC,

We had a very productive discussions at TC and DefCore meetings.  Thank you.

We've got more activity coordinated for this week including beyond the TC meeting.  I believe that will resolve any outstanding issues around the designated sections discussion.

The included text is the result of two DefCore meetings and reflects your input as discussed in those meetings.  Since these are moving targets, I am certain that some positions have shifted; however, I thought it is important to bring you the options that we have outlined so far.

These are intended as evolving talking points for our discussion, not a recommendation at this point.

Thanks,

TEXT FROM https://docs.google.com/document/d/1HYwxVjVDhLYD4zE8MraT-3l5lKoOCV8AKXfPRmW_ASc/edit?usp=sharing FOLLOWS:


TC Comments: https://review.openstack.org/#/c/74483/2/resolutions/20140211-tc_defcore_response



The following reflects positions discussed at the 3/3/2014 and  3/20 DefCore meetings.



Also: https://etherpad.openstack.org/p/openstack-designated-sections



The DefCore committee believes that it is critical for OpenStack to design designated sections in support of the "Core Principles" approved by the Board in Hong Kong.  While the principles do not require TC action, we greatly prefer a TC to lead in definition.  We recognize that the TC consensus position does not match the DefCore expectation and accept your offer of an interactive meeting to help resolve the question.



Note: We could get by with only defining designated sections for projects that are likely to have must-pass tests; however, this undermines the broader clarity of having clear upstreaming expectations.



Here are the three four options that were discussed in our meeting:



Option 0 - DefCore & TC Collaboration (added after DefCore E6<https://etherpad.openstack.org/p/DefCoreElephant.6> discussion)



DefCore and TC work together to define general principles that are used to define designated sections.  Together, the committees work out details needed to resolve immediate questions and figure out topics that can be deferred to future cycles.   These principles become part of the PTL incubation checklist and are applied retroactively to integrated projects.  The projects are prioritized based on which are most likely to have must-pass tests.



This approach is the strongest position for the OpenStack community because it shows Board and TC alignment.



Option 1 - using TC guidance that Nova & Swift = 100%, All others 0%



The implication for this option is that operators have only the most minimal upstream requirements; OpenStack clouds that pass the required tests can use any backing code as long as code from these two projects is included.  This potentially opens the door for completely different implementations of Keystone, Glance, Cinder, Neutron, etc.  It also undermines non-upstream API extensions, schedulers and backends.



DefCore believes that this position will be negatively viewed by the larger community and press.



Option 2 - allow PTLs to define per project



The implication for this option is that there is no unifying governance for how designated sections are selected.  This may result in sweeping changes per release as different PTLs take over projects.



This approach aligns with the original intent of the principles.



Option 3 - DefCore led definition



The implication for this option is DefCore & Board overreach that would not serve the community.  The DefCore has a strawperson draft of designated <https://etherpad.openstack.org/p/openstack-designated-sections> sections and would like to work with the TC and PTLs to help resolve the consensus position that addresses the obvious areas and leaves unclear areas for further discussion.

If DefCore leads this process, we will also define guiding principles to help with selection.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140324/b9e8cfa6/attachment.html>