Open Stack

Rob - With my Branding hat on, it's less about API uptake and more about the connotation of the Brand on a release. If the OpenStack Brand on a distro means a promise of quality, interoperability and backward compatibility how can we deliver on that for new capabilities without having evaluated them and ensure there's appropriate testing?

Carol

From: Rob Hirschfeld [mailto:rob at zehicle.com]
Sent: Thursday, February 26, 2015 4:41 PM
To: Barrett, Carol L; Rob Hirschfeld; Shamail
Cc: defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Trying to explain Guidelines... here's what I'm thinking [feedback welcome]

Carol,

Let me turn that around.  If a project released new capabilities out of cycle, how quickly would you expect them to surface into the DefCore guidelines?

By design, we select for widely-used APIs.  So, how fast should we expect a new feature to get wide adoption.

Rob
On 02/26/2015 03:48 PM, Barrett, Carol L wrote:
I expect that the unpredictability of project releases will create challenges in many ways. Branding is one of them - if a project releases new capabilities out of cycle to the core-projects release of the Defcore definition update, those new features will not be covered by the Brand (which means they haven't been validated to a certain level nor is there any backward API compatibility promise). How will an end-user know that?  If the Brand doesn't simplify the purchasing process for the end-user, then we're not on the right track..imho.

From: Rob Hirschfeld [mailto:rob at rackn.com]
Sent: Thursday, February 26, 2015 1:42 PM
To: Shamail
Cc: Barrett, Carol L; defcore-committee at lists.openstack.org<mailto:defcore-committee at lists.openstack.org>
Subject: Re: [OpenStack-DefCore] Trying to explain Guidelines... here's what I'm thinking [feedback welcome]

Good questions.  We're including which releases are covered in each guideline so, for example, you can track DefCore 2015.07 to the I,J & K releases.  You can't use that guideline against H or L

On Thu, Feb 26, 2015 at 3:38 PM, Shamail <itzshamail at gmail.com<mailto:itzshamail at gmail.com>> wrote:
Hi Carol,

I agree with the concern but I think (I didn't attend the F2F) some of this may be driven by the fact that we don't necessarily have a concrete definition of what a release may look like in the future.

If the releases (due to project structure reform) end up having a cadence with a usual group of components then I could see aligning with releases but I think some of that is TBD at this point, therefore this seems like a safe bet.

Thanks,
Shamail



> On Feb 26, 2015, at 3:52 PM, Barrett, Carol L <carol.l.barrett at intel.com<mailto:carol.l.barrett at intel.com>> wrote:
>
> 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<mailto:rob at zehicle.com>]
> Sent: Thursday, February 26, 2015 11:37 AM
> To: defcore-committee at lists.openstack.org<mailto: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<tel: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<mailto:Defcore-committee at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

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



--
Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob at rackn.com<mailto:rob at rackn.com>)

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




_______________________________________________

Defcore-committee mailing list

Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee



--





Rob

____________________________

Rob Hirschfeld, 512-773-7522



I am in CENTRAL (-6) time

http://robhirschfeld.com

twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20150227/98b2a89a/attachment.html>