[OpenStack Foundation] DefCore Update on Designated Sections, please disccuss/+1

Rob_Hirschfeld at Dell.com Rob_Hirschfeld at Dell.com
Sat Aug 16 20:27:46 UTC 2014


Board Members,

Note: if you'd like a quick DefCore review, please read http://robhirschfeld.com/2014/08/12/patchwork-onion/

Last week, the DefCore committee had an open meeting to create the initial strawman Design Sections.  This strawman is intended as the basis for discussion leading up to an official DefCore recommendation at the September Board meeting.  We are planning to have open community discussion meetings for this in a few weeks after reviewing with the TC and other leaders.

Before we do that, we felt that the Board should have a chance to +1 and discuss the recommendations.  The recommendations are based on 10 principles (in the post script)

RECOMMENDATIONS:

·         Havana Nova is by default designated except scheduler, filter, drivers, API extensions and networking.

·         Havana Swift has no designated code due to lack of consensus (see principles)

·         Havana Keystone is not designated.

·         Havana Glance designated sections are the API implementation code and domain model.

·         Havana Cinder designated sections are the API implementation code

·         Havana Neutron has no designated sections.

·         Havana Heat is not a core capability, no position at this time.

·         Havana Horizon is not a core capability, no position at this time.

·         other projects do not are not core capabilities and are not reviewed at this time.

10 PRINCIPLES POST SCRIPT:
Should be DESIGNATED:
1.    code provides the project external REST API, or
2.    code is shared and provides common functionality for all options, or
3.    code implements logic that is critical for cross-platform operation
Should NOT be DESIGNATED:
4.    code interfaces to vendor-specific functions, or
5.    project design explicitly intended this section to be replaceable, or
6.    code extends the project external REST API in a new or different way, or
7.    code is being deprecated
8.     UNdesignated by Default
§  Unless code is designated, it is assumed to be undesignated.
§  This aligns with the Apache license.
§  We have a preference for smaller core.
9.      Designated by Consensus
§  If the community cannot reach a consensus about designation then it is considered undesignated.
§  Time to reach consensus will be short: days, not months
§  Except obvious trolling, this prevents endless wrangling.
§  If there's a difference of opinion then the safe choice is undesignated.
10.      Designated is Guidance
§  Loose descriptions of designated sections are acceptable.
§  The goal is guidance on where we want upstream contributions not a code inspection police state.
§  Guidance will be revised per release as part of the DefCore process.



Rob
______________________________
Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140816/54501869/attachment-0001.html>


More information about the Foundation mailing list