Last modified: 2014-10-16 11:52:52 UTC
Right now, we have the "Bug: 12345" keyword, which causes Gerrit Notification Bot to comment and mark the bug as PATCH_NEEDS_REVIEW and comment again when it's merged. However, it doesn't mark it as Resolved: Fixed when it's merged. I think this is because tagging it with a Bug number does not always mean the bug is always fixed. If there were a Fixes-Bug keyword, that would allow automatically marking the bug as fixed without ambiguity. Using this keyword would mean that the current patch set alone is sufficient to fix the bug (any prior steps are already merged). "Bug: 12345" would remain available, for when the patch set was just one step towards fixing the bug.
(In reply to comment #0) > However, it doesn't mark it as Resolved: Fixed when it's merged. I think > this is because tagging it with a Bug number does not always mean the bug is > always fixed. I always assumed not marking the bug as resolved/fixed was a feature to prevent false positives. Determining whether a bug is resolved by a particular changeset can be difficult, even for experienced humans. > "Bug: 12345" would remain available, for when the patch set was just one step > towards fixing the bug. I can't say I'm a huge fan of the idea of having two very similar keywords. I think it will create confusion. But meh.
(In reply to comment #1) > (In reply to comment #0) > > However, it doesn't mark it as Resolved: Fixed when it's merged. I think > > this is because tagging it with a Bug number does not always mean the bug is > > always fixed. > > I always assumed not marking the bug as resolved/fixed was a feature to > prevent > false positives. Determining whether a bug is resolved by a particular > changeset can be difficult, even for experienced humans. I fully agree. > > "Bug: 12345" would remain available, for when the patch set was just one step > > towards fixing the bug. > > I can't say I'm a huge fan of the idea of having two very similar keywords. I > think it will create confusion. I fully agree here as well.
(In reply to comment #1) > > Determining whether a bug is resolved by a particular > > changeset can be difficult, even for experienced humans. > > I fully agree. And that's why I'm suggesting humans explicitly write "Fixes-Bug" in their commit message, when applicable. > > I can't say I'm a huge fan of the idea of having two very similar keywords. I > > think it will create confusion. > > I fully agree here as well. I don't think it's that confusing. We're talking about two keywords, and the one that marks it fixed has the word "Fixes" in the message. However, we could rename Bug: to Related-Bug: to make it even clearer.
(In reply to comment #3) > And that's why I'm suggesting humans explicitly write "Fixes-Bug" in their > commit message, when applicable. Right. I understand the function and utility of the proposed keyword. > I don't think it's that confusing. We're talking about two keywords, and the > one that marks it fixed has the word "Fixes" in the message. I see this as a design issue, though. With the introduction of a second bug-related keyword, the immediate question becomes: which do I use? Do I use both? Do I use just one? What if it fixes a bug, but for some reason I don't want the bug to be auto-marked as fixed? And this design issue reverberates onto other people who might be trying to use the keyword(s). Does everyone now have to account for both when running reports? > However, we could rename Bug: to Related-Bug: to make it even clearer. Sure, a lot of things could be done. I'm just not sure what issue is trying to be solved here. I don't think there's any significant efficiency gain here. People really interested in auto-marked as fixed could surely set up a script of their own that stalks their merged commits, though doing so would still be a bad idea for the reasons mentioned above, in my opinion.
The primary use case is for bug reporters, not developers: gerrit-bot being able to tell you that code that /fixes/ the bug has been pushed to gerrit (or merged) is much more interesting that "some related code that may be a million miles from fixing this bug might have changed state, maybe".
(In reply to comment #4) > I see this as a design issue, though. With the introduction of a second > bug-related keyword, the immediate question becomes: which do I use? Do I use > both? Do I use just one? What if it fixes a bug, but for some reason I don't > want the bug to be auto-marked as fixed? You use Fixes-Bug if it it fixes the bug. You use Bug otherwise. I can't think of any scenario you would tag it Fixes-Bug but not want it marked fixed. In that unlikely case, you would use Bug. > And this design issue reverberates onto other people who might be trying to > use the keyword(s). Does everyone now have to account for both when running > reports? I don't think there are any reports on bug status built on parsing commit message. > Sure, a lot of things could be done. I'm just not sure what issue is trying > to be solved here. I don't think there's any significant efficiency gain here. I disagree. I frequently have to go and manually change fixed bugs from PATCH_TO_REVIEW to FIXED, both things I have fixed and things other people have fixed. I'm obviously not the only one. > People really interested in auto-marked as fixed could surely set up a script > of their own that stalks their merged commits, though doing so would still > be a bad idea for the reasons mentioned above, in my opinion. It makes no sense for everyone to do it separately. This is really very common functionality for integrations between bug trackers and version control.
(In reply to comment #5) > The primary use case is for bug reporters, not developers: gerrit-bot being > able to tell you that code that /fixes/ the bug has been pushed to gerrit (or > merged) is much more interesting that "some related code that may be a > million miles from fixing this bug might have changed state, maybe". And you want to deprive humans the opportunity to enlighten (and excite!) the masses with the good news? ;-) (In reply to comment #6) > This is really very common functionality for integrations between bug > trackers and version control. [[WP:OKAY]]. I do some peripheral work (not much in Gerrit, but I'm active in Bugzilla and somehow I'm now maintaining Gerrit reports) and I think this change wouldn't be a great idea to implement. However, I don't think it's worth arguing about either way: I don't like the idea and I explained why. I'll leave it at that. :-)
*** Bug 39402 has been marked as a duplicate of this bug. ***
a) +1. b) Opportunity for bikeshedding: OpenStack uses "Closes-Bug", "Partial-Bug" and "Related-Bug" (cf. https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references). Personally, I prefer "Fixes-Bug" because it is unambiguous how the bug should be closed ("FIXED"). Glancing over https://gerrit.googlesource.com/plugins/hooks-bugzilla/+/master/src/main/resources/Documentation/config.md and the mention of "Fixes-Issue" there, this seems to be fairly straightforward to set up. Can someone give an estimate what is actually needed to implement this?
