[Starlingx-discuss] r/2018.10 branch merges complete

[Penney, Don]

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 at gmail.com] 
Sent: Monday, October 01, 2018 4:40 PM
To: Penney, Don
Cc: JONES, BRUCE; starlingx-discuss at 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 at 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 at gmail.com