Page MenuHomePhabricator

Add two new statuses to the workflow: patch released and patch committed.
Closed, ResolvedPublic

Description

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


Version: unspecified
Severity: enhancement

Details

Reference
bz39402

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:53 AM
bzimport set Reference to bz39402.
bzimport added a subscriber: Unknown Object (MLST).

and there can be a bot to move patch-released to resolved-fixed after some time?

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 ***