Hi,
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set some tag in bugzilla. At some point somebody approves and merges the patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much remembering involved for my taste. It's easy to forget to close the bug in bugzilla, especially if the patch has been lying around for some time before being merged.
Would it be possible/sensible to automatically close a bug when the patch is merged? Or did I miss something?
Cheers, Stephan
On Thu, Nov 8, 2012 at 12:54 PM, Stephan Gambke s7eph4n@gmail.com wrote:
Hi,
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set some tag in bugzilla. At some point somebody approves and merges the patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much remembering involved for my taste. It's easy to forget to close the bug in bugzilla, especially if the patch has been lying around for some time before being merged.
Would it be possible/sensible to automatically close a bug when the patch is merged? Or did I miss something?
In theory, yes. Someone already started writing a plugin to do the same thing for Jira[0]. Might be a good starting place for a Bugzilla plugin (and RT?).
-Chad
On Thu, 2012-11-08 at 13:00 -0500, Chad wrote:
Would it be possible/sensible to automatically close a bug when the patch is merged? Or did I miss something?
In theory, yes. Someone already started writing a plugin to do the same thing for Jira[0]. Might be a good starting place for a Bugzilla plugin (and RT?).
http://www.theoldmonk.net/gitzilla/ exists but I cannot offer any field reports. Current workflow is cumbersome ("patch-in-gerrit" keyword which should express a "patch to review" bug status). Automatic closing of reports as RESOLVED FIXED via a bot from Gerrit/Git could also have its cornercases (e.g. merging several patches across components, support reverting of Git merges by reopening Bugzilla ticket?, etc.). Would require some thoughts and testing.
andre
On Thu, 08 Nov 2012 09:54:43 -0800, Stephan Gambke s7eph4n@gmail.com wrote:
Hi,
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set some tag in bugzilla. At some point somebody approves and merges the patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much remembering involved for my taste. It's easy to forget to close the bug in bugzilla, especially if the patch has been lying around for some time before being merged.
Would it be possible/sensible to automatically close a bug when the patch is merged? Or did I miss something?
Cheers, Stephan
That would require two things: A) Far more integration between Gerrit and Bugzilla than we currently have. B) An assumption that every commit that mentions a bug actually fixes it.
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
Maybe we should start a new branch per-bug instead, and merge the branch when the bug is fixed? That might help with this issue.
On Thu, Nov 8, 2012 at 1:57 PM, Mark Holmquist mtraceur@member.fsf.org wrote:
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
Maybe we should start a new branch per-bug instead, and merge the branch when the bug is fixed? That might help with this issue.
I don't really like that idea either. How about instead of auto-closing, we at least have Gerrit tell BZ a patch was committed/submitted? That would save the "I've put a patch in <url>" step, and would prompt people on the CC list to possibly close when Gerrit says "Patch <foo> was submitted." Gerrit could probably tweak the keywords as well.
-Chad
On 08/11/12 20:00, Chad wrote:
I don't really like that idea either. How about instead of auto-closing, we at least have Gerrit tell BZ a patch was committed/submitted? That would save the "I've put a patch in <url>" step, and would prompt people on the CC list to possibly close when Gerrit says "Patch <foo> was submitted." Gerrit could probably tweak the keywords as well.
-Chad
It's the bit I like most. Although the problem is not notifying bugzilla of the new patch, but the merge. Maybe the bot should fire on merge, and if there was a bug mentioned in the merged patch and if in that bug one of the last comments begins with "Fixed in " + a url to the merged change, automatically leave a message "Change X merged by Foo" and close the bug as resolved fixed.
Maybe we need a Waiting_merge status in bugzilla.
2012/11/8 Mark Holmquist mtraceur@member.fsf.org:
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
Maybe we should start a new branch per-bug instead, and merge the branch when the bug is fixed? That might help with this issue.
What about changes like https://gerrit.wikimedia.org/r/#/c/29422/, which mentions bug 1, but obviously doesn't entirely fix it?
-- Matma Rex
What about changes like https://gerrit.wikimedia.org/r/#/c/29422/, which mentions bug 1, but obviously doesn't entirely fix it?
It wouldn't be put into the branch, or maybe it would be put into the branch but the branch would never get closed. But I like Chad's idea better, currently.
On 11/08/2012 07:43 PM, Daniel Friesen wrote:
Would it be possible/sensible to automatically close a bug when the patch is merged? Or did I miss something?
That would require two things: A) Far more integration between Gerrit and Bugzilla than we currently have. B) An assumption that every commit that mentions a bug actually fixes it.
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
I do not know enough about Gerrit and how hard it would be to implement this, but B could be solved by having some popup that asks the person merging a patch if the patch fixes the bug mentioned in the commit message.
Cheers, Stephan
"Daniel Friesen" daniel@nadir-seen-fire.com wrote:
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set some tag in bugzilla. At some point somebody approves and merges the patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much remembering involved for my taste. It's easy to forget to close the bug in bugzilla, especially if the patch has been lying around for some time before being merged.
Would it be possible/sensible to automatically close a bug when the patch is merged? Or did I miss something?
That would require two things: A) Far more integration between Gerrit and Bugzilla than we currently have. B) An assumption that every commit that mentions a bug actually fixes it.
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
Then why did you invent B only to rail against it? Just use a reasonable pattern, e. g. "This fixes bug #(\d+)."
Tim
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
Then why did you invent B only to rail against it? Just use a reasonable pattern, e. g. "This fixes bug #(\d+)."
At my last job, we used 2 different keywords to either associate the patch with the bug, or close the bug. Maybe something like that would work?
Le 08/11/12 19:43, Daniel Friesen wrote: <snip>
And I really don't like the idea of B. I can easily see people mentioning bugs that are related to a commit in the commit message but not directly fixed by it.
We could use an explicit convention such as: close #1234
2012/11/8 Stephan Gambke s7eph4n@gmail.com:
Hi,
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set some tag in bugzilla. At some point somebody approves and merges the patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much remembering involved for my taste. It's easy to forget to close the bug in bugzilla, especially if the patch has been lying around for some time before being merged.
This is not a big problem. If you forget to mark the bug as fixed, somebody will stumble upon it sooner or later, try to reproduce it, notice that it's fixed and mark it accordingly. -- Amir
Stephan Gambke s7eph4n@gmail.com wrote:
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set some tag in bugzilla. At some point somebody approves and merges the patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much remembering involved for my taste. It's easy to forget to close the bug in bugzilla, especially if the patch has been lying around for some time before being merged.
Would it be possible/sensible to automatically close a bug when the patch is merged? Or did I miss something?
Bug #17322.
Tim
wikitech-l@lists.wikimedia.org