[OpenStack-DefCore] Trying to explain Guidelines... here's what I'm thinking [feedback welcome]
Rob Hirschfeld
rob at zehicle.com
Fri Feb 27 17:03:00 UTC 2015
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20150227/432baadd/attachment-0001.html>
More information about the Defcore-committee
mailing list
