Open Stack

I am concerned about achieving the Brand goal,  using a month/year approach rather than a release approach. Is the expectation that a vendor will pull the upstream  for the month/year Defcore test and ship a product?  If a vendor release cycle is offset by 2 months, what would use to validate their Brand compliance? My thought is by that time new things will be included in a variety of projects that will be included in the Vendor release but not comprehended in the 2 month old Defcore definition.

Carol

-----Original Message-----
From: Rob Hirschfeld [mailto:rob at zehicle.com] 
Sent: Thursday, February 26, 2015 11:37 AM
To: defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Trying to explain Guidelines... here's what I'm thinking [feedback welcome]

Chris Lee pinged me about missing a note Component & Platform levels.  
We need to include that in the Guidelines.

Good catch Chris!

On 02/26/2015 12:46 PM, Rob Hirschfeld wrote:
> DefCore... does this explain Guidelines?
>
> Last week, the OpenStack DefCore committee rolled up our collective 
> sleeves and got to work in a serious way.  We had a in-person meeting 
> with great turn out with 5 board members, Foundation executives/staff 
> and good community engagement.
>
> TL;DR > We think DefCore should dated milestone guidelines instead 
> tightly coupled to release events (see graphic 
> https://robhirschfeld.files.wordpress.com/2015/02/defcore-timeline1.png).
>
> DefCore has a single goal expressed from two sides: 1) defining the 
> "what is OpenStack" brand for Vendors and 2) driving interoperability 
> between OpenStack installations.  From that perspective, it is not 
> about releases, but about testable stable capabilities.  Over time, 
> these changes should be incremental and, most importantly, trail 
> behind new features that are added.
>
> For those reasons, it was becoming confusing for DefCore to focus on 
> an "Icehouse" definition when most of the capabilities listed are 
> "Havana" ones.  We also created significant time pressure to get the 
> "Kilo DefCore" out quickly after the release even though there were no 
> "Kilo" specific additions covered.
>
> In the face-to-face, we settled on a more incremental approach. 
> DefCore would regularly post a set of guidelines for approval by the 
> Board.  These Guidelines would include the required, deprecated
> (leaving) and advisory (coming) capabilities required for Vendors to 
> use the mark (see footnote*).  They would also include the relevant 
> designated sections.  These Guidelines would use the open draft and 
> discussion process that we are in the process of outlining for 
> approval in Vancouver.
>
> Since DefCore Guidelines are simple time based lists of capabilities, 
> the vendors and community can simply reference an approved Guideline 
> using the date of approval (for example DefCore 2015.03) and know 
> exactly what was included.  While each Guideline stands alone, it is 
> easy to compare them for incremental changes.
>
> We've been getting positive feedback about this change; however, we 
> are still discussing it appreciate your input and questions. It is 
> very important for us to make DefCore simple and easy.  For that, your 
> confused looks and WTF? comments are very helpful.
>
> * footnote: the Foundation manages that process the Vendors. DefCore 
> Guidelines are just one part of the brand process.
>

-- 
   

Rob
____________________________
Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


_______________________________________________
Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee