My thought was to try and get some parallel effort going, do the resync as a continuing task as suffer a little ongoing pain versus a large amount of pain at the end. Given that the steps for a resync are the same no matter when we do it waiting until the end is acceptable.
>From a `just do it' perspective I think we're in violent agreement on the top >level tasks, as long as your step 3, integration testing, is the same as what >I've been calling working functionality, e.g. have the nova scheduler use the >gantt source tree. PS: How I resync. What I've done is create a list with md5sums of all the files in nova that we've duplicated in gantt. I then update a nova git tree and compare the current md5sums for those files with my list. I use format-patch to get the patches from the nova tree and grep for any patch that applies to a gantt file. I then use `git am' to apply those patches to the gantt tree, modifying any of the patches that are needed. It may sound a little cumbersome but I've got some automated scripts that make it relatively easy and modifying the patches, the hard part, was going to be necessary no matter how we do it. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Wednesday, January 15, 2014 10:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [gantt] Sync up patches On Wed, Jan 15, 2014 at 8:52 AM, Dugger, Donald D <donald.d.dug...@intel.com<mailto:donald.d.dug...@intel.com>> wrote: 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. 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. 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. 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. Great, so I would prefer to see gantt gating on unit tests before landing any other patches. 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): 1) Get unit tests working 2) Trim repo 3) Set up integration testing (In parallel get gantt client working) 4) Resync with nova 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. Fair enough, I moved trimming after get unit tests working in the list above. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786<tel:303%2F443-3786> From: Joe Gordon [mailto:joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>] Sent: Wednesday, January 15, 2014 9:28 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [gantt] Sync up patches On Tue, Jan 14, 2014 at 2:22 PM, Dugger, Donald D <donald.d.dug...@intel.com<mailto:donald.d.dug...@intel.com>> wrote: All- 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. 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? 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. 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. I'm not sure if I agree with the ordering proposed here. I would rather see gantt be trimmed first. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786<tel:303%2F443-3786> From: Dugger, Donald D Sent: Tuesday, January 14, 2014 2:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [gantt] Sync up patches All- 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: https://review.openstack.org/66717 It's be good if we can get those reviewed soon. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786<tel:303%2F443-3786> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
