Topic on Talk:Gerrit/Advanced usage

More discussion on wikitech-l: November 2012, ...

The page lacks instructions about what to do with bugzilla. The only relevant passages are:

• If your commit addresses a bug in Bugzilla, please comment on that bug to note that the commit is in the merge queue, and link to its changeset in Gerrit.
• If you merge a commit that references a Bugzilla bug, please go to that bug and mark it RESOLVED: FIXED and reference the merge ID.

How to become a MediaWiki hacker#Pushing for review through Gerrit says:

• Post a link to your Gerrit changeset in the appropriate bug report in Bugzilla with gerrit <changenumber>, and mark it with the patch and patch-need-review keywords.

I don't think it makes sense to have the code review queue for open commits on two separate tools?

What we're seeing is that most people mark the bug as fixed as soon as they commit the fix (otherwise they forget to), the dev who merges definitely marks as resolved fixed (although sometimes they forget) and then when further tested should be marked as verified fixed (by the reporter) or reopened. It's very confusing what one is actually supposed to do though.

We don't have currently a CLOSED state; which is supposed to say "fix made it into the release / and got deployed".

Sometimes we consider things FIXED once they are deployed on Wikimedia; sometimes it's when they go into the release.

I'd propose RESOLVED+FIXED to be done on merge, so that the requestor can make it VERIFIED FIXED using trunk.

We should decide whether CLOSED is "went into the release" or "got deployed" and when.

• Push a commit that fixes a ticket (or rather, claims to fix - since it is not reviewed yet).
  • Should mention the ticket ID in the commit-msg ("(bug 0000) Did foo and bar, made quux work again").
  • Comment on the ticket saying a proposed patch for this bug has been pushed to the review queue (mention gerrit change-id number or hash. Hash is probably better since numbering is less stable).
• A fix is reviewed/merged into the repo
  • Mark related tickets as resolved/fixed.

Optionally:

• Somebody using master verified that it works for him. This includes testing on a live Wikimedia project after deployment (since we deploy from master now - be it in a temporary branch, but those are always based on the latest master at that time). The user may mark it VERIFIED?

What the meaning of CLOSED isn't really relevant, since we don't use it and don't have it enabled.

• Pushing a commit with a proposed fix should change the bug status to fix released. We don't have any equivalent to this status in bugzilla, creating this status would be useful. I'd suggest adding the keyword "patch-in-gerrit" for bugs in the review queue.

• A fix is reviewed/merged into the repo - this should change bug status to fix-committed. We don't have any equivalent to this status in bugzilla. I'd suggest changing the resolved/fixed status to resolved/committed, and move the keyword.
  • The reporter or anyone who tested it and saw it's working can set the status to resolved/verified.

I think that the dev who merges should change the status of the bug after merging.

• I'd like if we could have an other field in bugzilla which would have the gerrit link, so we don't need to scroll all the way to the comment mentioning the link to the fix. Matanya (talk) 06:36, 15 August 2012 (UTC)

“

Pushing a commit with a proposed fix should change the bug status to fix released. We don't have any equivalent to this status in bugzilla, creating this status would be useful. I'd suggest adding the keyword "patch-in-gerrit" for bugs in the review queue.

”

+1. status for "there exists a fix in gerrit that will probably get reviewed" would be useful

We added a patch-in-gerrit keyword yesterday for this.

An actual status in Bugzilla would be welcome in addition to (or instead of) a keyword. It would make notifications more obvious, and provide a better interface for setting it (dropdown list vs. freeform text input)

Note that Mer Project's Bugzilla has a workflow with an additional step that might help clarifying things: RESOLVED FIXED (patch merged/committed to codebase) -> RELEASED (fix included in tarball) -> VERIFIED (reporter checked that commit actually fixed the issue). Bugzilla4 allows custom workflows in its settings. I agree that the Gerrit commit link should be more advertised. Adding "gerrit <changenumber>" currently is not too helpful as that is not even automatically turned into a direct link (compared to "bug <bugid>").

"gerrit change I88239c2b" worked just fine on this bug.

Ah, thanks, so the second word "change" is needed. That's not clear from the instructions.

The instructions "Post a link to your Gerrit changeset in the appropriate bug report in Bugzilla with gerrit <changenumber>, and mark it with the patch and patch-need-review keywords" contradicts the actual behavior that I see in Bugzilla (people asking to remove the "patch-need-review" keyword after a patch has been sent to Gerrit for review). Definitely needs fixing plus clarification on https://bugzilla.wikimedia.org/describekeywords.cgi