[Starlingx-discuss] r/2018.10 branch merges complete
It looks like the last of the 'setup' reviews for the r/2018.10 branch merged a few hours ago, thank you to those who reviewed those. This means that a) master is open again for ongoing work b) we are ready to do release branch builds directly from Gerrit via stx-manifest (check out r/2018.10 and use that default.xml) Don't forge that bug fixes should merge in master before being backported to r/2018.10. dt -- Dean Troyer dtroyer@gmail.com
Dean, thank you! I'm looking forward to seeing posts to the mailing list of successful builds on the branch, hint hint :) brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Monday, October 1, 2018 10:02 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] r/2018.10 branch merges complete It looks like the last of the 'setup' reviews for the r/2018.10 branch merged a few hours ago, thank you to those who reviewed those. This means that a) master is open again for ongoing work b) we are ready to do release branch builds directly from Gerrit via stx-manifest (check out r/2018.10 and use that default.xml) Don't forge that bug fixes should merge in master before being backported to r/2018.10. dt -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
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? -----Original Message----- From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Monday, October 01, 2018 1:14 PM To: Dean Troyer; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] r/2018.10 branch merges complete Dean, thank you! I'm looking forward to seeing posts to the mailing list of successful builds on the branch, hint hint :) brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Monday, October 1, 2018 10:02 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] r/2018.10 branch merges complete It looks like the last of the 'setup' reviews for the r/2018.10 branch merged a few hours ago, thank you to those who reviewed those. This means that a) master is open again for ongoing work b) we are ready to do release branch builds directly from Gerrit via stx-manifest (check out r/2018.10 and use that default.xml) Don't forge that bug fixes should merge in master before being backported to r/2018.10. dt -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
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
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
[Grrr... gmail changed on me this weekend and the new quoting looks like crap...sorry] On Mon, Oct 1, 2018 at 3:52 PM Penney, Don <Don.Penney@windriver.com> wrote:
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
This sounds fine. You could even run it through the check pipeline while waiting. The flow you mention below is also good (cp in the web ui). FWIW I usually do what you did above mostly because I want to run the tests locally first.
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.
The practice in OpenStack has been to wait for the review on master to merge. This is in part because it was a different group that ultimately approved stable backports, this is no longer necessarily true for many projects. We can decide how strict to be on that matter, I would suggest that we be reasonably sure that it will merge on master before +W on the backport. This case sounds pretty safe as you say but unless there is a reason to be in a hurry
Side note: After 1h42, Zuul has passed the "check" and is running the "gate". So it will likely be merged very shortly.
Zuul does seem to be doing better so far this week. dt -- Dean Troyer dtroyer@gmail.com
participants (3)
-
Dean Troyer
-
Jones, Bruce E
-
Penney, Don