<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 7:07 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">On 04/29/2013 08:57 AM, Thierry Carrez wrote:<br>
</div><div class="im HOEnZb">> It can look like this:<br>
> * Copy the code to a new project, make it work<br>
> * File and get accepted for incubation before mid-H cycle<br>
> * Graduate at the end of H to be an Integrated project in I<br>
><br>
> The only tricky bit is, can we mark nova-baremetal deprecated in H<br>
> release, while there is no Ironic "integrated" release before the "I"<br>
> release time ? Or should nova-baremetal be marked deprecated at the<br>
> start of the I cycle and fully removed in J ?<br>
><br>
> Given that nova-baremetal is pretty new and that we should have a usable<br>
> version of Ironic around H release time, I think marking nova-baremetal<br>
> deprecated in Havana Nova is acceptable...<br>
<br>
</div><div class="im HOEnZb">This all sounds good to me.  One other thing I would note is the<br>
importance of some sort of migration path.  We released it, so we need<br>
to carry those users along into the Ironic world.  As long as that is<br>
covered in the H development timeframe, I wouldn't have a problem<br>
marking nova-baremetal deprecated in H.<br>
<br>
--<br>
Russell Bryant<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra" style>Maybe it would make more sense rather than deciding how fast the project is promoted today, instead we focus on acceptance of the separate project, and further in the cycle make the determination of incubation status etc.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Even with Cinder this is how we went about it, we didn't say up front "skip incubation" as I recall.  Instead, we first decided "yes/no" on new project, then around the third milestone IIRC we voted on the next phase, incubation or skip etc based on how things went during the release cycle (gerrit, following the process etc etc).</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Just my opinion but I don't think there's enough data to say today/this week that we should "skip incubation" and short cut.  If we look at how things are shaping up 3 months from now we'd actually have data to put into the context of the decision.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>John</div></div>