[OpenStack-DefCore] Trying to explain Guidelines... here's what I'm thinking [feedback welcome]
Monty Taylor
mordred at inaugust.com
Fri Feb 27 17:08:37 UTC 2015
On 02/27/2015 12:03 PM, Rob Hirschfeld 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
>
>
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
More information about the Defcore-committee
mailing list
