[OpenStack-DefCore] Trying to explain Guidelines... here's what I'm thinking [feedback welcome]
Rob Hirschfeld
rob at rackn.com
Sun Mar 1 18:40:45 UTC 2015
Shamail,
I think that needs to be a subject of discussion once we start getting
some data.
My gut is that we'd want to see at least 70% penetration of a API set.
That means that in 70% of the reports, we see 100% passing of the tests
in the capability. Said another way, 7 out of 10 OpenStack
implementations (reporting results) would have that capability in a
fully functioning way.
I don't know if that's the right cut off - the only way to know is to
compare it against other capabilities. I am very confident that we'll
see a clear in/out range once we start collecting data. I just don't
know the actual %.
I hope that helps.
Rob
On 02/27/2015 12:43 PM, Shamail wrote:
> How do we define "broad adoption"? Should we state some threshold or
> criteria or will it be subjective for now?
>
> Thanks,
> Shamail
>
>
>
> On Feb 27, 2015, at 12:03 PM, Rob Hirschfeld <rob at zehicle.com
> <mailto:rob at zehicle.com>> wrote:
>
>> YES! very very well said.
>>
>> On 02/27/2015 10:38 AM, Barrett, Carol L wrote:
>>>
>>> Thanks Rob – so when capabilities become accepted in the market
>>> Defcore ensures support for them moving forward, until it’s no
>>> longer appropriate.
>>>
>>> I’ll take up my branding concerns with the marketing side of the house.
>>>
>>> Carol
>>>
>>> *From:*Rob Hirschfeld [mailto:rob at zehicle.com]
>>> *Sent:* Friday, February 27, 2015 8:36 AM
>>> *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,
>>>
>>> DefCore can't. IMHO, it one of Vendors' roles to select, validate
>>> and support new capabilities. DefCore comes along after those
>>> capabilities are broadly adopted. It would be an anti-pattern if we
>>> selected capabilities that were only in one or two products/distros.
>>>
>>> The reason to move away from releases was to decouple this exact
>>> discussion. DefCore is not about features in releases but long term
>>> capabilities of the platform.
>>>
>>> Rob
>>>
>>> On 02/27/2015 10:00 AM, Barrett, Carol L wrote:
>>>
>>> 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
>>> <mailto: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
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Rob
>>> ____________________________
>>> Rob Hirschfeld, 512-773-7522
>>>
>>> I am in CENTRAL (-6) time
>>> http://robhirschfeld.com
>>> twitter: @zehicle, github: cloudedge & ravolt
>>
>> --
>>
>>
>> Rob
>> ____________________________
>> Rob Hirschfeld, 512-773-7522
>>
>> I am in CENTRAL (-6) time
>> http://robhirschfeld.com
>> twitter: @zehicle, github: cloudedge & ravolt
--
Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO, Founder
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/20150301/a9d089b9/attachment-0001.html>
More information about the Defcore-committee
mailing list
