The process I've followed here for the backport, partly due to waiting for Zuul to process the original review, is: - Cloned r/2018.10 - Cherry-picked the original review, using the cmd provided by Gerrit: - Build a load (in progress) - Re-test In this particular case, the change is small enough (and the difference between master and r/2018.10 is minimal at this point) that I'd feel comfortable with a straight cherry-pick. For other changes, I think the build and retest steps would be important. I suppose I could have used the "cherry-pick" button on Gerrit and then downloaded that update into my repo for the testing, setting workflow to -1 while I complete testing, but I thought I should wait until the update had been merged, based on your original email. Side note: After 1h42, Zuul has passed the "check" and is running the "gate". So it will likely be merged very shortly. -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Monday, October 01, 2018 4:40 PM To: Penney, Don Cc: JONES, BRUCE; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] r/2018.10 branch merges complete On Mon, Oct 1, 2018 at 3:21 PM Penney, Don <Don.Penney@windriver.com> wrote:
For backporting a fix to r/2018.10, I've got a repo setup on that branch and cherry-picked the change, and I'm building a load to test while waiting for Zuul to process the update to master. Maybe a stupid question, but do I need to change the "Change-Id" for the commit (ie. delete it and amend the commit) to avoid collision with the original when I create the new gerrit review?
No, in fact for cherry-picking you want the change-id to be the same. Gerrit understands this and will do it for you if you do the cherry-pick in the web UI. This simplifies matching the reviews. dt -- Dean Troyer dtroyer@gmail.com