Issues are tracked at


Issues that do not have a contributor actively working on them may be in one of three states:

  • New: issue has not had initial review yet.
  • AwaitingInformation: issue needs more detail attached.
  • Accepted: problem reproduced or feature request acknowledged.

Issues being worked on should change the status to let others know it may be resolved in the near future:

  • Started: a contributor has begun work on this issue.
  • ChangeUnderReview: a change for this issue been uploaded for code review.

Closed states resolve an issue:

  • Submitted: a fix has been submitted to a stable branch or the master branch and will be included in a future release.
  • Released: a release has been announced including this fix.


Priority Target Response Time Resolution
Priority-0 1 working day “soon”
Priority-1 5 working days  
Priority-2 30 working days best effort
Priority-3 - best effort
Priority-4 - best effort

As explained on the support page the Gerrit community aims to achieve the target response times that are documented above, but there IS NO guaranteed Service Level Agreement.


  • Critical issue causing failures in production.
  • Major functionality broken that renders a feature unusable.


  • Urgent; the issue is blocking a user from getting their job done.
  • Breakage blocking next release (e.g. Guice injectors).
  • Defect causing functional regression in production.
  • Production issue impacting customers.


  • Work tied to roadmap, or near term upcoming release.
  • Inconvenient bug that should be addressed in one of the next few releases.


  • We feel your pain: the team would like to fix this, but lacks the resources to do this soon. Gerrit is an open-source project; contributions are appreciated.
  • Desirable feature or enhancement not on the roadmap.


  • Ponies and icebox.
  • Unfortunate: it’s a legitimate issue, but the team never plans to fix this.


  • Type-Bug is broken functionality.
  • Type-Feature is a request for new feature or enhancement.



The new web interface built in Polymer. Issues in this component are actively managed by PolyGerrit maintainers involved in the daily development efforts.


Related to the change metadata in Git project, which is migrating Gerrit off the SQL “ReviewDb” database.


Issue is unique to the family of servers, including This covers both administration support required (e.g. correct a broken user account) and issues unique to the server’s plugins (e.g. authentication/web sessions or secondary index).


Issues for a plugin project hosted under plugins/. Actively developed plugins may have their own subcomponent.



All bugs require to specify the Gerrit version the bug was found in. This helps to categorize bugs and clean up stale bugs.


The engineer working on fixing an issue can set “TargetMilestone” to specify the Gerrit version they expect to deliver the fix.