Open Stack

Just because I love giving you a hard time ... the should/should not 
sections below copy/pasted poorly, so it looks like it's all a list of 
"should not" :)

In case anyone else read it that way first, the first set of bullets are 
should and the second are should not.

BTW - I'd like to explicitly give a shout out to the following sentences:

"Loose descriptions of designated sections are acceptable.  The goal is 
guidance on where we want upstream contributions not a code inspection 
police state."

That may be the best expression I've seen yet of the underlying intent 
for this to be helpful, and not legalistically prescriptive and 
nitpicky. Thanks!

On 08/11/2014 11:15 AM, Rob_Hirschfeld at Dell.com wrote:
> All,
>
> I mean AUGUST 14th.    Sorry for the confusion.
>
> Rob
>
> From: Hirschfeld, Rob
> Sent: Monday, August 11, 2014 11:01 AM
> To: Defcore-committee at lists.openstack.org
> Subject: [OpenStack-DefCore] DefCore Thursday 10am @ DLA Piper office
>
> All,
>
> DLA Piper is hosting the Thurs 10/14 @ 10am DefCore meeting.
>
> Call in & Agenda: https://etherpad.openstack.org/p/DefCoreLighthouse.5
>
> The address is
> 2000 University Avenue
> East Palo Alto, California
>
>
> Also, it looks like we have agreement on the principles.  I am planning a blog post to socialize them.
>
> Rob
>
> From: Hirschfeld, Rob
> Sent: Thursday, August 07, 2014 1:04 AM
> To: Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>
> Subject: [OpenStack-DefCore] PLEASE DISCUSS (or +1) Designated Sections Principles [No Meeting on Friday]
>
> All,
>
> We did not get critical mass on the doodle calendars to justify a meeting.  I am planning a meeting next Thursday (10 am?) to draft the strawman.  I'll be in SF and looking for a location (South Bay is ok).
>
> Josh and I have the following proposal for "designated sections principles" based on the TC's original document:
>
> Should be DESIGNATED:
>
> Should NOT be DESIGNATED:
>
> §  code provides the project external REST API, or
> §  code is shared and provides common functionality for all options, or
> §  code implements logic that is critical for cross-platform operation
>
> §  code interfaces to vendor-specific functions, or
> §  project design explicitly intended this section to be replaceable, or
> §  code extends the project external REST API in a new or different way, or
> §  code is being deprecated
>
>
> There are three important additions to these 7 points:
>
>
> 1)      unless code is designated, it is assumed to be undesignated.  As usual, we have a preference for smaller core.
>
> 2)      If the community cannot reach a fast consensus about designation then code is considered undesignated.  Excepting obvious trolling, this prevents endless wrangling.   If there's a true difference of opinion then we default to undesignated.
>
> 3)      Loose descriptions of designated sections are acceptable.  The goal is guidance on where we want upstream contributions not a code inspection police state.
>
>
> Rob
> ______________________________
> Rob Hirschfeld
> Sr. Distinguished Cloud Solution Architect
> Dell | Cloud Edge, Data Center Solutions
> cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
> Please note, I am based in the CENTRAL (-6) time zone
>
>
>
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>