Last modified: 2013-08-31 22:33:49 UTC
Please add those statuses to bugzilla for easier track of real bug status. Some dev change the status to resolved fixed when the push the fix to gerrit for code review, some don't change it until a merge, and some forget at all. The suggestion is to have fix released at patch being in code review and fix committed at merge. after the patch is live bug can move to resolved fixed. to change in bugzilla: administration --> field values --> Status -->Add a value. Thanks
and there can be a bot to move patch-released to resolved-fixed after some time?
I'm planning to write one.
I'm not quite sure how necessary this is needed. Some people use fixed at commit/review, and then mark it verified when it's testable live. This needs discussing on wikitech-l/mediawiki-l before adding new states
As I already wrote in https://www.mediawiki.org/wiki/Thread:Talk:Git/Workflow/Bugzilla : bugs.merproject.org and bugs.meego.com have a workflow with an additional step that might help clarifying things: RESOLVED FIXED (patch merged/committed to codebase) -> RELEASED (fix included in tarball [or deployed in case of the WFM instance?]) -> VERIFIED (reporter checked that commit actually fixed the issue).
(In reply to comment #1) > there can be a bot to move patch-released to resolved-fixed after some time? Also see http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064317.html > after the patch is live bug can move to resolved fixed That's very Wikimedia specific while commits go also into MediaWiki. To me, RESOLVED FIXED == patch has been merged, not necessarily deployed on a website (like Wikimedia), so I disagree with a "patch committed" status.
To reevaluate after (In reply to comment #0) > Some dev change the status to resolved fixed when the push the fix to gerrit > for code review That cannot be FIXED because nobody knows yet if that code change fixes the bug or even works. Hence this part is a no-go to me. WONTFIX. > have fix released at patch being in code review Some status like "patch in gerrit" could be considered, but only after bug 17322 is fixed. Such a status should preferably be set automatically, hence adding dependency. > and fix committed at merge. Fix committed means RESOLVED FIXED nowadays.
*** Bug 40985 has been marked as a duplicate of this bug. ***
Once we have a process agreed let's remember to document or link it at https://www.mediawiki.org/wiki/Gerrit/Tutorial Currently the only references to Bugzilla there are: ** Push your change set to Gerrit ... 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. ** Comparing patch sets ... 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.
> patch released The Gerrit Notification Bot automatically set the status PATCH_TO_REVIEW and adds a comment, so I consider this part of the request FIXED. > patch committed This means that the patch got merged. The Gerrit Notification Bot automatically adds a comment, but I am currently not yet convinced whether we should automatically close as RESOLVED FIXED. The discussion about this takes place in bug 53387, so I am marking this as a duplicate. *** This bug has been marked as a duplicate of bug 53387 ***