Hi Brandon, Doug Thanks for your explanations and feedback I think I understand now what should be done.
I made a commit today to my TLS change https://review.openstack.org/#/c/109035 And my barbican module change https://review.openstack.org/#/c/109849 It caused: 1. patch commit to "New extension for version 2 of LBaaS API" change with some addition to neutron.conf file probably because I made a fresh neutron clone. 2. patch commit to " Plugin/DB additions for version 2 of LBaaS API "change with empty line deletion in migration HEAD file 3. patch commit to " Tests for extension, db and plugin for LBaaS V2 "change with same addition to neutron.conf file My commit caused the changes to be scheduled to gate tests Gate tests failed because of a new alembic migration that was merged yesterday - 31d7f831a591, so migration timeline is broken now Brandon, it should be fixed in order to pass the gate. When your changes will be fixed, I will rebase mine. So it looks OK now, except the gate failure that should be fixed The dependency tree is: https://review.openstack.org/#/c/109035 - TLS (Evg) depends on https://review.openstack.org/#/c/109849 Barbican module(Evg) depends on https://review.openstack.org/#/c/105610 tests (Brandon) depends on https://review.openstack.org/#/c/105609 DB (Brandon) depends on https://review.openstack.org/#/c/105331 extension (Brandon) Thanks, Evg -----Original Message----- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Wednesday, July 30, 2014 3:39 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Managing change in gerrit which depends on multiple other changes in review Hi Evgeny and Doug, So the thing to keep in mind is that Gerrit determines a new review by the change-id in the commit message. It then determines patch sets by the commit hashes. This is my understanding of it at least. A commit's hash gets changed on many actions such as cherry-picks, rebases, and commit --amend. With this in mind, this means that you can verify if your changes will not cause an update to the ancestor changes in a gerrit dependency chain. Before you do a git review just look at your git log and commit hashes and see if the hash for each of those commits are the same as the latest patch sets in gerrit. My workflow is this: If I just need to rebase the change, I just hit the rebase button in gerrit on my change only. This will cause the commit to have a new hash, thus a new patch set. If I need to make a change then just doing the normal git checkout from the gerrit change page, and git commit --amend works fine, because I am only touching that commit. If I need to make a change AND rebase there are two ways to do this: 1. Hit Rebase Button on the gerrit change page then git checkout, make change, git commit --amend, git review. - The problem with this is that it creates two patch sets. 2. git checkout the gerrit change that your gerrit change is dependent on. Then cherry-pick your gerrit change on top of that. This is essentially a rebase, and now you can make changes to the code, commit --amend and git review. Gerrit will only see this commit hash changed once, so only one patch set. One other thing to keep in mind is since your change is dependent on others you have to rely on your change's dependents to be rebased with master. You shouldn't do a rebase against master until the change you are dependent on has been merged. So the only time you should rebase is when gerrit shows the OUTDATED message on your dependency. Hope that helps explain my methodology, which is still a work in progress. However, I think this is a decent methodology when dealing with a massive dependency chain like this. Thanks, Brandon On Tue, 2014-07-29 at 16:05 +0000, Doug Wiegley wrote: > Hi Evgeny, > > > I’m not sure I’m doing it in the most efficient way, so I’d love to > hear pointers, but what I’ve been doing: > > > First, to setup the dependent commit, the command is “git review –d”. > I’ve been using this > guide: > http://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Create_a_dependenc > y > > > Second, when the dependent review changes, there is a ‘rebase’ button > on gerrit that’ll get things back in sync automatically. > > > Third, if you need to change your code after rebasing from gerrit, > this is the only sequence I’ve tried that doesn’t result in something > weird (rebasing overwrites the dependent commits, silently, so I’m > clearly doing something wrong): > 1. Re-clone vanilla neutron > 2. Cd into new clone, setup for gerrit review > 3. Redo dependent commit setup > 4. Create your topic branch > 5. Cherry-pick your commit from gerrit into your new topic branch > 6. Use "git log -n5 --decorate --pretty=oneline”, and verify that > your dependency commit hashes match what’s in gerrit. > 7. Git review > > > Thanks, > doug > > > > > From: Evgeny Fedoruk <evge...@radware.com> > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > Date: Tuesday, July 29, 2014 at 7:12 AM > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [Neutron] Managing change in gerrit which > depends on multiple other changes in review > > > > Hi folks, > > > > I’m working on a change for neutron LBaaS service. > > Since there is a massive work done for LBaaS these days, my change > depends on other changes being reviewed in parallel in gerrit. > > I don’t have a big git knowledge and I’m failing in figuring out the > right procedure that should be followed for managing such a > multi-dependent patch. > > So, I sending my question to you guys, in hope to find the right way > to manage such patches in gerrit. > > > > Here is the situation: > > There are 4 patches on review in gerrit > > 1. A – No dependencies > > 2. B – Depends on A > > 3. C – Depends on A > > 4. D – No dependencies > > > > > > My change, let’s call it “X”, is already on review in gerrit. > > It should depend on all four other changes, A, B, C and D. > > > > I tried to two ways of managing those dependencies, 1) by doing a > cherry-pick for each one of them, and 2) by doing git review and git > rebase for each one of them. > > It does not work for me well, my change commit message is replaced by > other changes’ commit messages and when I commit my patch, it commit’s > other changes patches too. > > > > So, my question is: > > Is this scenario supported by gerrit system? > > If it does – what is the right procedure to follow in order to manage > those dependencies > > and how to rebase my change when some of dependencies was commited > with a new patch to keep the dependencies up-to-date? > > > > > > Thank you! > > Evg > > > > > _______________________________________________ > OpenStack-dev mailing list > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
