Hello,
It was just just brought to my attention by Yongqin that after upgrade, all open changes appear to be stuck at "Merge Conflict" state, which is easily visible in the summary table:
https://android-review.linaro.org/#/q/status:open
Checking any single change, e.g. https://android-review.linaro.org/#/c/15987/ it says "Cannot Merge", and tooltip says "due to a path conflict". There's no "Rebase" button, tooltip says that rebasing should happen locally, and new version uploaded. Yongqin tried that with https://android-review.linaro.org/#/c/15996/ , and it cleared state and change was merged successfully after that.
So, there's nothing fatal, but of course it's quite a chore to rebase all patches manually. My googling for what could be the cause of such problem after an upgrade, unfortunately didn't turn up much so far. But there're a lot of older (circa 2010) discussions of Gerrit behavior when harmless, not really conflicting concurrent commits to a repo threw changes into such state. They all relate to the times when Gerrit didn't support automatic conflict resolution or it was conservatively disabled. But on android-review.linaro.org, we exactly have those conservative "off" settings of circa-2.4 times.
So, my hypothesis is that's what played role in such situation with upgrade, and i propose to have more process-friendly settings.
Specifically, currently we have:
Submit Type: Merge if necessary Automatically resolve conflicts: FALSE Require Change-Id in commit message: FALSE
I propose to change it to:
Submit Type: Rebase if necessary Automatically resolve conflicts: TRUE Require Change-Id in commit message: TRUE
Let me know if there're any concerns.
Not that these are "avoid problems in the future" changes, current conflicting changes will need to be re-uploaded by their authors manually.
That sounds reasonable to me Paul, glad it was noticed today and not next week :)
On 6 August 2015 at 15:27, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
It was just just brought to my attention by Yongqin that after upgrade, all open changes appear to be stuck at "Merge Conflict" state, which is easily visible in the summary table:
https://android-review.linaro.org/#/q/status:open
Checking any single change, e.g. https://android-review.linaro.org/#/c/15987/ it says "Cannot Merge", and tooltip says "due to a path conflict". There's no "Rebase" button, tooltip says that rebasing should happen locally, and new version uploaded. Yongqin tried that with https://android-review.linaro.org/#/c/15996/ , and it cleared state and change was merged successfully after that.
So, there's nothing fatal, but of course it's quite a chore to rebase all patches manually. My googling for what could be the cause of such problem after an upgrade, unfortunately didn't turn up much so far. But there're a lot of older (circa 2010) discussions of Gerrit behavior when harmless, not really conflicting concurrent commits to a repo threw changes into such state. They all relate to the times when Gerrit didn't support automatic conflict resolution or it was conservatively disabled. But on android-review.linaro.org, we exactly have those conservative "off" settings of circa-2.4 times.
So, my hypothesis is that's what played role in such situation with upgrade, and i propose to have more process-friendly settings.
Specifically, currently we have:
Submit Type: Merge if necessary Automatically resolve conflicts: FALSE Require Change-Id in commit message: FALSE
I propose to change it to:
Submit Type: Rebase if necessary Automatically resolve conflicts: TRUE Require Change-Id in commit message: TRUE
Let me know if there're any concerns.
Not that these are "avoid problems in the future" changes, current conflicting changes will need to be re-uploaded by their authors manually.
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
+1.
On 6 August 2015 at 20:06, Matt Hart matthew.hart@linaro.org wrote:
That sounds reasonable to me Paul, glad it was noticed today and not next week :)
On 6 August 2015 at 15:27, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
It was just just brought to my attention by Yongqin that after upgrade, all open changes appear to be stuck at "Merge Conflict" state, which is easily visible in the summary table:
https://android-review.linaro.org/#/q/status:open
Checking any single change, e.g. https://android-review.linaro.org/#/c/15987/ it says "Cannot Merge", and tooltip says "due to a path conflict". There's no "Rebase" button, tooltip says that rebasing should happen locally, and new version uploaded. Yongqin tried that with https://android-review.linaro.org/#/c/15996/ , and it cleared state and change was merged successfully after that.
For merging any patch, one can revert to older screen on https://android-review.linaro.org/#/settings/preferences and then should be able to use the rebase button as well as submit. This seems to be issue with the new screen.
So, there's nothing fatal, but of course it's quite a chore to rebase all patches manually. My googling for what could be the cause of such problem after an upgrade, unfortunately didn't turn up much so far. But there're a lot of older (circa 2010) discussions of Gerrit behavior when harmless, not really conflicting concurrent commits to a repo threw changes into such state. They all relate to the times when Gerrit didn't support automatic conflict resolution or it was conservatively disabled. But on android-review.linaro.org, we exactly have those conservative "off" settings of circa-2.4 times.
So, my hypothesis is that's what played role in such situation with upgrade, and i propose to have more process-friendly settings.
Specifically, currently we have:
Submit Type: Merge if necessary Automatically resolve conflicts: FALSE Require Change-Id in commit message: FALSE
I propose to change it to:
Submit Type: Rebase if necessary Automatically resolve conflicts: TRUE Require Change-Id in commit message: TRUE
Let me know if there're any concerns.
Not that these are "avoid problems in the future" changes, current conflicting changes will need to be re-uploaded by their authors manually.
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On 7 August 2015 at 20:07, Vishal Bhoj vishal.bhoj@linaro.org wrote:
+1.
On 6 August 2015 at 20:06, Matt Hart matthew.hart@linaro.org wrote:
That sounds reasonable to me Paul, glad it was noticed today and not next week :)
On 6 August 2015 at 15:27, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
It was just just brought to my attention by Yongqin that after upgrade, all open changes appear to be stuck at "Merge Conflict" state, which is easily visible in the summary table:
https://android-review.linaro.org/#/q/status:open
Checking any single change, e.g. https://android-review.linaro.org/#/c/15987/ it says "Cannot Merge", and tooltip says "due to a path conflict". There's no "Rebase" button, tooltip says that rebasing should happen locally, and new version uploaded. Yongqin tried that with https://android-review.linaro.org/#/c/15996/ , and it cleared state and change was merged successfully after that.
For merging any patch, one can revert to older screen on https://android-review.linaro.org/#/settings/preferences and then should be able to use the rebase button as well as submit. This seems to be issue with the new screen.
So, there's nothing fatal, but of course it's quite a chore to rebase all patches manually. My googling for what could be the cause of such problem after an upgrade, unfortunately didn't turn up much so far. But there're a lot of older (circa 2010) discussions of Gerrit behavior when harmless, not really conflicting concurrent commits to a repo threw changes into such state. They all relate to the times when Gerrit didn't support automatic conflict resolution or it was conservatively disabled. But on android-review.linaro.org, we exactly have those conservative "off" settings of circa-2.4 times.
So, my hypothesis is that's what played role in such situation with upgrade, and i propose to have more process-friendly settings.
Specifically, currently we have:
Submit Type: Merge if necessary Automatically resolve conflicts: FALSE Require Change-Id in commit message: FALSE
I propose to change it to:
Submit Type: Rebase if necessary Automatically resolve conflicts: TRUE Require Change-Id in commit message: TRUE
+100 :)
Let me know if there're any concerns.
Not that these are "avoid problems in the future" changes, current conflicting changes will need to be re-uploaded by their authors manually.
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-android@lists.linaro.org