<div dir="ltr">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 </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 26, 2015 at 3:38 PM, Shamail <span dir="ltr"><<a href="mailto:itzshamail@gmail.com" target="_blank">itzshamail@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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">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">rob@zehicle.com</a>]<br>
> Sent: Thursday, February 26, 2015 11:37 AM<br>
> To: <a 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 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" value="+15127737522">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">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">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">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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px">Rob</span><br style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px">____________________________</span><br style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px">Rob Hirschfeld, 512-773-7522</span><br style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px">RackN CEO/Founder (<a href="mailto:rob@rackn.com" target="_blank">rob@rackn.com</a>)</span><br style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><br style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px">I am in CENTRAL (-6) time</span><br style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><a href="http://robhirschfeld.com" target="_blank">http://robhirschfeld.com</a></span><br style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px">twitter: @zehicle, github: cloudedge & ravolt</span><br></div></div>
</div>