Last modified: 2014-05-21 11:08:31 UTC
With the introduction of the recent PATCH_TO_REVIEW automatic logic, now the Gerrit to Bugzilla bot will re-open bugs and post notifications if patch sets are uploaded for WMF branches. In other words, if a patch fixing a bug is merged on master, and the bug is thus marked as FIXED, and then it is backported to another branch, the bot will re-open the bug and post notifications about it.
In general, uploading a new change for a bug in RESOLVED state should bring it back to PATCH_TO_REVIEW state. That looks sane. For backporting, this behaviour looks like it's not optimal. How can we detect that a commit is a backport? Filtering branches for “^wmf/.*” looks error-prone as then we would not have PATCH_TO_REVIEW set automatically, when implementing geniune bug-fixes for a wmf branch. Does this only affect core, or also extensions?
(In reply to comment #1) > In general, uploading a new change for a bug in RESOLVED state should > bring it back to PATCH_TO_REVIEW state. That looks sane. > > For backporting, this behaviour looks like it's not optimal. > > How can we detect that a commit is a backport? > > Filtering branches for “^wmf/.*” looks error-prone as then we would > not have PATCH_TO_REVIEW set automatically, when implementing geniune > bug-fixes for a wmf branch. Also the REL1_XX branches. I think its sane to not reopen bug if bug is both in a closed state and the branch is not master.
Checking for closed state requires to query bz beforehand, which is currently not possible. But that sounds like a worthwhile solution.
I would like to see this fixed, because it is annoying, when a resolved bug gets PATCH_TO_REVIEW due to backporting.
Most of the backports will have a "cherry picked from commit", maybe in that case a status change on bugzilla is not needed.
