<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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<br>
<br>
<div class="moz-cite-prefix">On 02/27/2015 10:00 AM, Barrett, Carol
L wrote:<br>
</div>
<blockquote
cite="mid:2D352D0CD819F64F9715B1B89695400D5C6B5BF1@ORSMSX113.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<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?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Carol<o:p></o:p></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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 class="moz-txt-link-freetext" href="mailto:rob@zehicle.com">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 class="moz-txt-link-abbreviated" href="mailto:defcore-committee@lists.openstack.org">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]<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></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<o:p></o:p></p>
<div>
<p class="MsoNormal">On 02/26/2015 03:48 PM, Barrett, Carol L
wrote:<o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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 moz-do-not-send="true"
href="mailto:rob@rackn.com">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 moz-do-not-send="true"
href="mailto:defcore-committee@lists.openstack.org">
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><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></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 <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Thu, Feb 26, 2015 at 3:38 PM,
Shamail <<a moz-do-not-send="true"
href="mailto:itzshamail@gmail.com" target="_blank">itzshamail@gmail.com</a>>
wrote:<o:p></o:p></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
moz-do-not-send="true"
href="mailto:carol.l.barrett@intel.com">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
moz-do-not-send="true" href="mailto:rob@zehicle.com">rob@zehicle.com</a>]<br>
> Sent: Thursday, February 26, 2015 11:37 AM<br>
> To: <a moz-do-not-send="true"
href="mailto:defcore-committee@lists.openstack.org">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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="tel:512-773-7522">512-773-7522</a><br>
><br>
> I am in CENTRAL (-6) time<br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif"">Rob<br>
____________________________<br>
Rob Hirschfeld, 512-773-7522<br>
RackN CEO/Founder (<a moz-do-not-send="true"
href="mailto:rob@rackn.com" target="_blank">rob@rackn.com</a>)<br>
<br>
I am in CENTRAL (-6) time<br>
<a moz-do-not-send="true"
href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a><br>
twitter: @zehicle, github: cloudedge & ravolt</span><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Defcore-committee mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Rob<o:p></o:p></pre>
<pre>____________________________<o:p></o:p></pre>
<pre>Rob Hirschfeld, 512-773-7522<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I am in CENTRAL (-6) time<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="http://robhirschfeld.com">http://robhirschfeld.com</a><o:p></o:p></pre>
<pre>twitter: @zehicle, github: cloudedge & ravolt <o:p></o:p></pre>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Rob
____________________________
Rob Hirschfeld, 512-773-7522
I am in CENTRAL (-6) time
<a class="moz-txt-link-freetext" href="http://robhirschfeld.com">http://robhirschfeld.com</a>
twitter: @zehicle, github: cloudedge & ravolt </pre>
</body>
</html>