<div dir="ltr">Hi Rob,<div><br></div><div>Thank you for the reply. The project usage data from the last user survey (e.g. <a href="http://a2.res.cloudinary.com/hqq9ey1mh/image/upload/c_limit,w_793/v1414983197/c4ctuijd67tmq4yfqtdc.png">here</a>) only shows services (and not API sets) being used by the respondents. If we were to compare the 70% adoption (and I know it was just a number you threw out) against survey data then Nova, Glance, Keystone, Horizon, and Cinder would be the only projects. I agree that the data from test reports will be needed before we can discuss further, i'll reinitiate the conversation at a later date. </div><div><br></div><div>Thanks,</div><div>Shamail Tahir</div><div>Cloud Architect, EMC</div><div>t: @ShamailXD</div><div>tz: Eastern</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 1:40 PM, Rob Hirschfeld <span dir="ltr"><<a href="mailto:rob@rackn.com" target="_blank">rob@rackn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Shamail,<br>
<br>
I think that needs to be a subject of discussion once we start
getting some data.<br>
<br>
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.<br>
<br>
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 %.<br>
<br>
I hope that helps.<br>
<br>
Rob<div><div class="h5"><br>
<br>
<div>On 02/27/2015 12:43 PM, Shamail wrote:<br>
</div>
<blockquote type="cite">
<div>How do we define "broad adoption"? Should we state some
threshold or criteria or will it be subjective for now?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Shamail <br>
<br>
<br>
</div>
<div><br>
On Feb 27, 2015, at 12:03 PM, Rob Hirschfeld <<a href="mailto:rob@zehicle.com" target="_blank">rob@zehicle.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
YES! very very well said.<br>
<br>
<div>On 02/27/2015 10:38 AM, Barrett,
Carol L wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks
Rob – so when capabilities become accepted in the
market Defcore ensures support for them moving
forward, until it’s no longer appropriate. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’ll
take up my branding concerns with the marketing side
of the house.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Carol<u></u><u></u></span></p>
<p class="MsoNormal"><a name="14bd6a4023036852__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
Rob Hirschfeld [<a href="mailto:rob@zehicle.com" target="_blank">mailto:rob@zehicle.com</a>]
<br>
<b>Sent:</b> Friday, February 27, 2015 8:36 AM<br>
<b>To:</b> Barrett, Carol L; Rob Hirschfeld;
Shamail<br>
<b>Cc:</b> <a href="mailto:defcore-committee@lists.openstack.org" target="_blank">defcore-committee@lists.openstack.org</a><br>
<b>Subject:</b> Re: [OpenStack-DefCore] Trying to
explain Guidelines... here's what I'm thinking
[feedback welcome]<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Carol,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Rob<u></u><u></u></p>
<div>
<p class="MsoNormal">On 02/27/2015 10:00 AM, Barrett,
Carol L wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Carol</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
Rob Hirschfeld [<a href="mailto:rob@zehicle.com" target="_blank">mailto:rob@zehicle.com</a>]
<br>
<b>Sent:</b> Thursday, February 26, 2015 4:41 PM<br>
<b>To:</b> Barrett, Carol L; Rob Hirschfeld;
Shamail<br>
<b>Cc:</b> <a href="mailto:defcore-committee@lists.openstack.org" target="_blank">defcore-committee@lists.openstack.org</a><br>
<b>Subject:</b> Re: [OpenStack-DefCore] Trying
to explain Guidelines... here's what I'm
thinking [feedback welcome]</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Carol,<br>
<br>
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?<br>
<br>
By design, we select for widely-used APIs. So, how
fast should we expect a new feature to get wide
adoption.<br>
<br>
Rob<u></u><u></u></p>
<div>
<p class="MsoNormal">On 02/26/2015 03:48 PM, Barrett,
Carol L wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Rob Hirschfeld [<a href="mailto:rob@rackn.com" target="_blank">mailto:rob@rackn.com</a>]
<br>
<b>Sent:</b> Thursday, February 26, 2015 1:42 PM<br>
<b>To:</b> Shamail<br>
<b>Cc:</b> Barrett, Carol L; <a href="mailto:defcore-committee@lists.openstack.org" target="_blank">
defcore-committee@lists.openstack.org</a><br>
<b>Subject:</b> Re: [OpenStack-DefCore] Trying to
explain Guidelines... here's what I'm thinking
[feedback welcome]</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">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 <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Thu, Feb 26, 2015 at 3:38
PM, Shamail <<a href="mailto:itzshamail@gmail.com" target="_blank">itzshamail@gmail.com</a>>
wrote:<u></u><u></u></p>
<p class="MsoNormal">Hi Carol,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Shamail<br>
<br>
<br>
<br>
> On Feb 26, 2015, at 3:52 PM, Barrett, Carol
L <<a href="mailto:carol.l.barrett@intel.com" target="_blank">carol.l.barrett@intel.com</a>>
wrote:<br>
><br>
> 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.<br>
><br>
> Carol<br>
><br>
> -----Original Message-----<br>
> From: Rob Hirschfeld [mailto:<a href="mailto:rob@zehicle.com" target="_blank">rob@zehicle.com</a>]<br>
> Sent: Thursday, February 26, 2015 11:37 AM<br>
> To: <a href="mailto:defcore-committee@lists.openstack.org" target="_blank">defcore-committee@lists.openstack.org</a><br>
> Subject: Re: [OpenStack-DefCore] Trying to
explain Guidelines... here's what I'm thinking
[feedback welcome]<br>
><br>
> Chris Lee pinged me about missing a note
Component & Platform levels.<br>
> We need to include that in the Guidelines.<br>
><br>
> Good catch Chris!<br>
><br>
>> On 02/26/2015 12:46 PM, Rob Hirschfeld
wrote:<br>
>> DefCore... does this explain
Guidelines?<br>
>><br>
>> Last week, the OpenStack DefCore
committee rolled up our collective<br>
>> sleeves and got to work in a serious
way. We had a in-person meeting<br>
>> with great turn out with 5 board
members, Foundation executives/staff<br>
>> and good community engagement.<br>
>><br>
>> TL;DR > We think DefCore should
dated milestone guidelines instead<br>
>> tightly coupled to release events (see
graphic<br>
>> <a href="https://robhirschfeld.files.wordpress.com/2015/02/defcore-timeline1.png" target="_blank">
https://robhirschfeld.files.wordpress.com/2015/02/defcore-timeline1.png</a>).<br>
>><br>
>> DefCore has a single goal expressed
from two sides: 1) defining the<br>
>> "what is OpenStack" brand for Vendors
and 2) driving interoperability<br>
>> between OpenStack installations. From
that perspective, it is not<br>
>> about releases, but about testable
stable capabilities. Over time,<br>
>> these changes should be incremental
and, most importantly, trail<br>
>> behind new features that are added.<br>
>><br>
>> For those reasons, it was becoming
confusing for DefCore to focus on<br>
>> an "Icehouse" definition when most of
the capabilities listed are<br>
>> "Havana" ones. We also created
significant time pressure to get the<br>
>> "Kilo DefCore" out quickly after the
release even though there were no<br>
>> "Kilo" specific additions covered.<br>
>><br>
>> In the face-to-face, we settled on a
more incremental approach.<br>
>> DefCore would regularly post a set of
guidelines for approval by the<br>
>> Board. These Guidelines would include
the required, deprecated<br>
>> (leaving) and advisory (coming)
capabilities required for Vendors to<br>
>> use the mark (see footnote*). They
would also include the relevant<br>
>> designated sections. These Guidelines
would use the open draft and<br>
>> discussion process that we are in the
process of outlining for<br>
>> approval in Vancouver.<br>
>><br>
>> Since DefCore Guidelines are simple
time based lists of capabilities,<br>
>> the vendors and community can simply
reference an approved Guideline<br>
>> using the date of approval (for example
DefCore 2015.03) and know<br>
>> exactly what was included. While each
Guideline stands alone, it is<br>
>> easy to compare them for incremental
changes.<br>
>><br>
>> We've been getting positive feedback
about this change; however, we<br>
>> are still discussing it appreciate your
input and questions. It is<br>
>> very important for us to make DefCore
simple and easy. For that, your<br>
>> confused looks and WTF? comments are
very helpful.<br>
>><br>
>> * footnote: the Foundation manages that
process the Vendors. DefCore<br>
>> Guidelines are just one part of the
brand process.<br>
><br>
> --<br>
><br>
><br>
> Rob<br>
> ____________________________<br>
> Rob Hirschfeld, <a href="tel:512-773-7522" target="_blank">512-773-7522</a><br>
><br>
> I am in CENTRAL (-6) time<br>
> <a href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a><br>
> twitter: @zehicle, github: cloudedge &
ravolt<br>
><br>
><br>
>
_______________________________________________<br>
> Defcore-committee mailing list<br>
> <a href="mailto:Defcore-committee@lists.openstack.org" target="_blank">Defcore-committee@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><br>
><br>
>
_______________________________________________<br>
> Defcore-committee mailing list<br>
> <a href="mailto:Defcore-committee@lists.openstack.org" target="_blank">Defcore-committee@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><br>
<br>
_______________________________________________<br>
Defcore-committee mailing list<br>
<a href="mailto:Defcore-committee@lists.openstack.org" target="_blank">Defcore-committee@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif"">Rob<br>
____________________________<br>
Rob Hirschfeld, <a href="tel:512-773-7522" value="+15127737522" target="_blank">512-773-7522</a><br>
RackN CEO/Founder (<a href="mailto:rob@rackn.com" target="_blank">rob@rackn.com</a>)<br>
<br>
I am in CENTRAL (-6) time<br>
<a href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a><br>
twitter: @zehicle, github: cloudedge &
ravolt</span><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Defcore-committee mailing list<u></u><u></u></pre>
<pre><a href="mailto:Defcore-committee@lists.openstack.org" target="_blank">Defcore-committee@lists.openstack.org</a><u></u><u></u></pre>
<pre><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre>Rob<u></u><u></u></pre>
<pre>____________________________<u></u><u></u></pre>
<pre>Rob Hirschfeld, <a href="tel:512-773-7522" value="+15127737522" target="_blank">512-773-7522</a><u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre>I am in CENTRAL (-6) time<u></u><u></u></pre>
<pre><a href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a><u></u><u></u></pre>
<pre>twitter: @zehicle, github: cloudedge & ravolt <u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre> <u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>Rob<u></u><u></u></pre>
<pre>____________________________<u></u><u></u></pre>
<pre>Rob Hirschfeld, <a href="tel:512-773-7522" value="+15127737522" target="_blank">512-773-7522</a><u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>I am in CENTRAL (-6) time<u></u><u></u></pre>
<pre><a href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a><u></u><u></u></pre>
<pre>twitter: @zehicle, github: cloudedge & ravolt <u></u><u></u></pre>
</div>
</blockquote>
<br>
<pre cols="72">--
Rob
____________________________
Rob Hirschfeld, <a href="tel:512-773-7522" value="+15127737522" target="_blank">512-773-7522</a>
I am in CENTRAL (-6) time
<a href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a>
twitter: @zehicle, github: cloudedge & ravolt </pre>
</div>
</blockquote>
</blockquote>
<br>
</div></div><pre cols="72"><div><div class="h5">--
Rob
____________________________
Rob Hirschfeld, <a href="tel:512-773-7522" value="+15127737522" target="_blank">512-773-7522</a></div></div>
RackN CEO, Founder
I am in CENTRAL (-6) time
<span class=""><a href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a>
twitter: @zehicle, github: cloudedge & ravolt </span></pre>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div style="font-size:small">Thanks,</div><div style="font-size:small">Shamail Tahir</div><div style="font-size:small">Cloud Architect, EMC</div><div style="font-size:small">t: @ShamailXD</div><div style="font-size:small">tz: Eastern Time</div></div></div>
</div></div>