The Gerrit open-source community actively supports the last 2 releases on a best effort basis. Older releases are not actively maintained but may still receive important fixes (e.g. security fixes), but there is no guarantee for this. Which fixes are backported to these old releases is decided on a case by case basis.
End of life for old release happens implicitly when a new Gerrit version is released, and is announced via the project news and on the mailing list.
The following table shows the current level of support for Gerrit releases:
|3.1||EOL||EOL since May 19, 2021|
|3.0||EOL||EOL since December 1st, 2020|
|2.16||EOL||EOL (with exceptions) since June 1st, 2020|
|2.15||EOL||EOL since November 15th, 2019|
|2.14||EOL||EOL since May 31st, 2019|
The same support status, as well as notes and documentation for every recent Gerrit release is detailed here.
Repo Discuss should be your first stop when you encounter an issue with Gerrit.
Here you will reach a majority of Gerrit contributors and Gerrit admins around the world. Often someone has had your issue before and can help you.
Many questions regarding Gerrit concerns are a direct result of local environment and configuration. Often such issues have already been discussed on the repo-discuss mailing list and you may find an answer by searching through the existing posts. If you have a new question, you can start a new discussion thread. Via the mailing list you can reach a plethora of Gerrit experts in our world wide community and benefit from their collective knowledge.
The repo-discuss mailing list is managed to prevent spam posts. This means posts from new participants must be approved manually before they appear on the mailing list. Approvals normally happen within 1 work day. Posts of people that participate in mailing list discussions frequently are approved automatically.
Using the mailing list, you can also request to be invited to the open Slack channel if prompted to. A maintainer or community manager should then be able to address your request. Please try accessing it first before issuing a request for it.
You could also check the questions tagged with “gerrit” on Stack Overflow.
Response time and SLO
Gerrit Code Review is an open-source project, which means that the people that are using the tool are invited to cooperate and join for contributing to its development and support. Opening new issues, triaging existing ones and helping to resolve them are ways of contributing to the project.
There is not a formal support contract amongst the members of the community, therefore there IS NO guaranteed Service Level Agreement on the response and resolution of the issues raised, but we are happy to define our SLO (Service Level Objectives). However, amongst ourselves, we are aiming to achieve the following response times, depending on the severity of the issue raised.
|Severity||Description||Target response time|
|P0||Major functionality broken that renders a feature unusable||1 working day|
|P1||Defect causing regression in production||5 working days|
|P2||Work tied to roadmap or near term upcoming release||30 working days|
|P3||Desirable feature or enhancement not in the roadmap||-|
NOTE: Bug reports about existing features are typically classified between P0 and P3, feature requests are classified between P2 and P4.
There are companies that are very active in developing and supporting Gerrit Code Review core and the associated plugins: see below a short non-exhaustive list of companies and their published support policies.
The Gerrit team at Google runs its own Gerrit deployment under the
googlesource.com domain. This deployment is in service of Google
projects that have external visibility or external partners. The
deployment is based on the latest development commit of Gerrit.
googlesource.com shares its business logic with the
publicly available gerrit code, but has important differences in
low-level backend details, such as resource scaling, account handling,
search index, and the git storage. It also lacks SSH support. Due to
this we often lack expertise to analyze backend bugs on ‘normal’
When filing a bug through the “report bug” link on googlesource.com,
we add the
host-googlesource label to filed bugs.
The frontend team at Google has a daily triage round to look at all frontend/UI bugs.
The backend team does a daily triage on bugs that have the
We look at all security bugs as a matter of policy.
GerritForge is UK-based Private Limited Company with a passion for Open-Source and is fully committed to providing all of its source code contributions and know-how to the community, including bug-fixes, features, plugins, help and support.
GerritForge has been active in the Gerrit Code Review community since GitTogether 2011, has contributed thousands of changes to the Gerrit platform and has been organizing the Gerrit User Summits and Hackathons since the London Hackathon 2013.
GerritForge provides free Community Support (CS) for the Gerrit community using two channels:
GerritForge monitors the channels on UK and EU working days, 8:00-23:00 GMT, and occasionally over week-ends and bank holidays. Although a response is not guaranteed for community support, we aim to meet the general Gerrit Support SLO.
NOTE: GerritForge does not answer to private e-mails or Slack direct messages under the CS umbrella, because the aim is to spread the knowledge with the whole community.
All Gerrit non-EOL releases are actively supported and GerritForge is happy, but not committed, to directly fix the issue. GerritForge also hosts the CI/CD pipeline for building the packaged artifacts for download.
GerritForge keeps an archive of EOL plugins builds on the CI/CD archive site. The plugins artifacts are available for download but not necessarily maintained or supported.
Gerrit EOL releases may also be supported, but not necessarily fixed, on a good-will basis, but only if the problem can be still relevant on a non-EOL version. All other problems and fixes associated with EOL releases fall within the scope of the GerritForge’s Enterprise support.
Enterprise Support (ES) is available to GerritForge customers for a fee using dedicated channels, monitored on a 24/7 basis, 365 days a year.
The response time is guaranteed by a strict SLA specified in the support contract terms and conditions.
See more details on the GerritForge Enterprise Support web-site.
If the issue/question you posted on Repo Discuss is considered a bug the community will ask you to create an issue for tracking it. Bugs are reported to the issue tracker. The issue tracker is not always the best place to initially request new features, as the main focus for those consuming it is fixing bugs.
The Gerrit project has adopted a feature request model where you are asked to submit your feature request together with some valid, general, use-cases.
All incoming issues should be triaged to decide on their priority. The priority should be based on the severity, the frequency and the risk of the issue.
Besides finding the right priority we also aim to clarify the issue so it is well understandable what the problem is.
The triage is not meant to investigate the cause of bugs or assign issues.
Triaging should include the following steps:
- Determine the right priority.
- Mark feature requests as
- Check that the component is correctly set, and update it if necessary.
- If necessary, update the issue summary to be clear.
- Set label
Securityif it’s a security or privacy issue.
- Close incomplete issues as
- Close spam issues as
Invalid, flag them as spam and then delete them.
- Check if the issue has been reported before and close it as
- Check if reproduction steps are present and clear. If not, ask the reporter
to provide them and set the status to
- Set the status to
Acceptedand add the label
Triaged-Yeswhen the triaging is done.
Triaging incoming issues is a community effort and is done on a best effort basis (also see above).