<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 8:52 AM, Dugger, Donald D <span dir="ltr"><<a href="mailto:donald.d.dugger@intel.com" target="_blank">donald.d.dugger@intel.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The current thought is that I will do the work to backport any change that are made to the nova tree that overlap the gantt tree.  I don’t see this as an impossible
 task.  Yes it will get harder as we make specific changes to gantt but, given that our first goal is to make gantt a drop in replacement for the nova scheduler there shouldn’t be that many gantt specific changes that would make backporting difficult so I think
 this is a doable path.</span></p></div></div></blockquote><div><br></div><div>How are you tracking this today? I think its worth having a well documented plan for this, as we will most likely have to keep syncing the two repos for a while.</div>

<div><br></div><div>If all that is needed to cherry-pick a patch from nova to gantt is a nova=>gantt rename these should be easy and a single +2 makes sense, but for any patch that requires changes beyond that I think a full review should be required.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><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"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For the ordering, the unit tests and working functionality are indeed effectively the same, highest priority, I don’t have an issue with getting the unit tests
 working first.</span></p></div></div></blockquote><div><br></div><div>Great, so I would prefer to see gantt gating on unit tests before landing any other patches.</div><div><br></div><div>Whats the full plan for the steps to bootstrap?  It would be nice to have a roadmap for this so we don't get bogged down in the weeds. Off the top of my head I imagine it would be something like (I have a feeling I am missing a few steps here): </div>

<div><br></div><div>1) Get unit tests working</div><div>2) Trim repo</div><div>3) Set up integration testing  (In parallel get gantt client working)</div><div>4) Resync with nova</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div lang="EN-US" link="blue" vlink="purple"><div><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"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As far as trimming is concerned I would still prefer to do that later, after we have working functionality.  Since trimable files won’t have gantt specific
 changes keeping them in sync with the nova tree is easy.  Until we have working functionality we won’t really know that a file is not needed (I am constantly surprised by code that doesn’t do what I expect) and deleting a file after we are sure it’s not needed
 is easy.</span></p></div></div></blockquote><div><br></div><div>Fair enough, I moved trimming after get unit tests working in the list above.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><div class="im">
<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">--<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Don Dugger<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">"Censeo Toto nos in Kansa esse decisse." - D. Gale<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ph: <a href="tel:303%2F443-3786" value="+13034433786" target="_blank">303/443-3786</a><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>
</div><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Joe Gordon [mailto:<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, January 15, 2014 9:28 AM</span></p><div class="im"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
</div><b>Subject:</b> Re: [openstack-dev] [gantt] Sync up patches<u></u><u></u><p></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Jan 14, 2014 at 2:22 PM, Dugger, Donald D <<a href="mailto:donald.d.dugger@intel.com" target="_blank">donald.d.dugger@intel.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="color:#1f497d">All-</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">I want to clear up some confusion I’m seeing in the reviews of these syncup patches.  These patches merely bring recent changes from the nova tree over
 to the gantt tree.  There is no attempt to actually change the code for gantt, that is a separate task.  Our first goal is to have the scheduler in gantt do exactly what the scheduler in nova does.  We want to be able to reliably change nova to use the gantt
 source tree as a drop in replacement, get that working before we start making gantt specific changes.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As far as I can tell this is the first time we have tried to fork a repository without a freeze on the original codebase (when we split out cinder, nova-volume was frozen).  With this form of forking, syncing the repos becomes harder, and
 I am concerned with the sync method proposed here.  Once we do the big rename (%s/nova/gantt/g) in the gantt repo, we can't just cherry-pick patches across without any modifications (assuming we gate on the unit tests). So going forward how are we planning
 on keeping the two repos in sync?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">Is there an outline of the bootstrap process for Gantt? I would imagine the first goal (before landing any sync patches) would be to get the unit tests working.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">The gantt tree probably has extra code that can be trimmed out later but, as long as that code exists in gantt I want to make it a synced up copy of
 the code in nova.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm not sure if I agree with the ordering proposed here. I would rather see gantt be trimmed first.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="color:#1f497d">--</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">Don Dugger</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">"Censeo Toto nos in Kansa esse decisse." - D. Gale</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">Ph:
<a href="tel:303%2F443-3786" target="_blank">303/443-3786</a></span><u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
</div>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Dugger, Donald D
<br>
<b>Sent:</b> Tuesday, January 14, 2014 2:48 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> [gantt] Sync up patches<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">All-<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">As threatened, I’ve pushed 24 patches to sync up the gantt tree to recent changes to the nova tree.  They’re all linked in a dependency chain starting at:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">               
<a href="https://review.openstack.org/66717" target="_blank">https://review.openstack.org/66717</a><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">It’s be good if we can get those reviewed soon.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">--<u></u><u></u></p>
<p class="MsoNormal">Don Dugger<u></u><u></u></p>
<p class="MsoNormal">"Censeo Toto nos in Kansa esse decisse." - D. Gale<u></u><u></u></p>
<p class="MsoNormal">Ph:
<a href="tel:303%2F443-3786" target="_blank">303/443-3786</a><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>