This update covers key discussions, events, and future planning points discussed by the Gerrit community team, reflecting recent activities and upcoming initiatives.
Recently the Git/Gerrit team at Google has undergone some changes after Ben Rohlfs left the project in 2025 to move to pastures anew. Ivo joined the Gerrit team as Engineering Manager late into 2025, he joins from the Bazel team and brings lot of Open-Source experience to the project, which is always great to see. Recently, he was joined by Terry, who will be overseeing all things Git at Google. Terry is a long standing member of the Gerrit community having worked alongside Shawn since the project was in its early stages.
Welcome Ivo and Terry, its great to have you guys join us and we’re looking forwarding to your input and support to the project.
We’re trying to start early with organizing the summit this year after last year’s great success. We put a first feeder out to the bazel community to co-locate it with BazelCon, however it looks like the venue won’t be able to support another event at the same time. We’ll keep speaking with interested parties and will update the community once a decisions has been made, hopefully with plenty of notice for people to organize their travel plan.
We discussed whether it makes sense to still keep a roadmap out as its not updated all that often and especially with how quickly things are changing in the age of AI. We agreed that its still important to have a document to show where the project is headed in the future, but maybe it doesn’t need to be as granular as it currently is.
Dani is to address Nasser’s comments and hopefully we can get this released soon.
Nasser has been taking the lead on these, however, we agreed that we should look to advertise them better and make people aware when they’re happening.
As there where a few recent changes that took quite some prodding to get merged Dani brought up the subject of Gitiles maintainership. Terry confirmed that its very much used within Google because of its powerful APIs but not as much as a code browser and if there are people happy to contribute to the UX we should aim to facilitate them. We’ll review activity on the repo in a few months and decide if anything needs to be done.
]]>Next meeting: February 25th, 2026
[LM] proposed a release plan for version 3.14 starting at the end of February, which was later suggested to be delayed by a month to align with a meetup and allow Thomas and David Ostrovski to finalize the migration to Bazel mode. [LM] also raised the change ID duplication issue, noting it is increasing, particularly with AI-driven workflows; [EK] confirmed Google also recently changed indexing for human users to be asynchronous to improve user experience, and [SZ] and [EK] see the issue less frequently. [LM], [SZ], and [EK] discussed the potential for calculating the change ID on the server and concluded that although the duplication issue is concerning, it is not a current priority over other issues like concurrency problems with the ref-table.
Draft Plan: [LM] drafted the release plan for version 3.14, initially proposing a start date at the end of February.
Bazel Migration: It was decided to check with Matias regarding the status of the migration
to bzlmod (managed by David Ostrovski and Thomas), as this could serve as a major feature for
the release.
Luca raised an issue where Gerrit generates the Change ID on the client side. This causes duplication problems when indexing is set to asynchronous or has high latency.
A similar duplication problem may happen with the change number duplication issue where the same change number is assigned to two changes on different projects.
Frequency: [SZ] and [EK] noted they see this issue less frequently. However, [EK] mentioned that Google recently switched to asynchronous indexing for human users performing git pushes to improve the User Experience (UX). All the web-ui interactions caused already asynchronous indexing.
AI Workflow Impact: [LM] observed an increase in clients reporting this issue, particularly those adopting AI-driven workflows which significantly increase push traffic.
[SZ] stated that a fix cannot be prioritized immediately as it likely requires updates to the global ref-db in a multi-master scenario. However, there are other issues to be solved on v3.14, such as ref-table concurrency, are currently higher priority.
Risk Assessment: [LM] agreed that while the issue is concerning regarding AI adoption, the probability of occurrence remains relatively low, in less than 0.1% of the cases.
Long-term solution: Solving this fundamentally would require a design document, potentially moving Change ID calculation from the client to the server, used in the ref-name of the change instead of the change number.
Current Mitigation: The preferred solution (implemented by Google) is to configure indexing as asynchronous for human users (to reduce push times) but keep it synchronous for agents/bots to prevent duplication.
Schedule Shift: Luca suggested delaying the 3.14 release start by one month, to allow a proper fix of the ref-table implementation and finalise the Bazel migration.
Sunnyvale Meetup: The new timeline aligns with the upcoming meetup in Sunnyvale on the 19th of February. This allows for a preview of version 3.14 (currently in master) while accommodating the migration work.
| Date | Activity |
|---|---|
| Mar 23 | Create stable-3.14 branch, Release 3.14.0-rc0 |
| Mar 30 | Release 3.14.0-rc1 |
| Apr 7 | Release 3.14.0-rc2 |
| Apr 13 | Release 3.14.0-rc3 - Feature freeze deadline. |
| Apr 20 | Release 3.14.0-rc4 |
| Apr 27 | Release 3.14.0-rc5 - Release freeze |
| May 5 | Final release of 3.14.0 |
There are plans for a Gerrit hackathon in TBC.
There is a gerrit-3_14-release Discord channel
dedicated to anyone willing to help with the development, testing and
documentation of this release.
We plan to use the Gatling e2e test framework for Git, developed by GerritForge and Ericsson to test the stability of the release on a production-like setup.
GerritForge, who is also offering Gerrit-as-a-Service on Google Cloud Marketplace, will be testing the scalability of Gerrit v3.14, particularly with medium to large-sized projects and in a multi-primary setup with Kubernetes on GKE.
Per the support policy mentioned in the project homepage, after 3.14.0 is released, 3.11.x will reach the end of life and will no longer be actively supported.
Support for 3.12.x and 3.13.x will continue as usual. Users of 3.11.x or earlier are recommended to upgrade to one of these versions.
]]>This update covers key discussions, events, and future planning points discussed by the Gerrit community team, reflecting recent activities and upcoming initiatives.
Yesterday saw the latest instalment of GerritMeets event in Munich, which was a great success, drawing an excellent crowd of over 70 attendees for a productive day of community collaboration and technical discussion.
Many thanks to GDG Cloud Munich organizers, Florian Haubner and Mike Annau from Google for helping us organise and supporting the event!
A major highlight was the return of official presentations from Google, marking the first time in a few years they have actively participated. This presence was highly welcomed and signals a strong internal interest in the Gerrit project’s ongoing development, as also demonstrated by the growing number of commits in Gerrit 3.13.
In terms of leadership, community members Dani, Matthias, and Luca connected with Ivo, the new manager of the Gerrit team. This introductory meeting was positive, and the community looks forward to a fruitful collaboration as the project progresses.
The technical agenda featured strong sessions, notably the presentation on the MCP server, which was extremely well-received. The technology demonstration prompted an insightful community discussion.
Dani also suggested that it would be nice if the MCP server would learn some SSH commands to provide further functionalities.
Sadly, this time round we did not manage to organize in time, we’ll target attending with a Gerrit stand in 2027.
Dani will try to abstract the plain english from the HTML pages to YAML files.
We’re still discussing this, Luca is planning to start a poll in the coming days with a carousel of the logos proposed in the past few years at the Gerrit events.
]]>Next meeting: January 28, 2026
[LM] confirmed the release plan is progressing: RC4 is out, the final RC is next Monday, and
the process is now fully automated with security improvements. [SZ] confirmed the Bazel
migration from WORKSPACE to bzlmod (to simplify dependencies) is in progress, [LM] proposed to
postpone its rollout to v3.14. Key topics also included the Lucene indexing issue (design doc pending),
new Gerrit tool integrations (JJ/GitButler), and the publication of
Gerrit Summit videos
ahead of an upcoming Munich GerritMeets event.
[LM] provided a status update on the release plan, noting that RC4 was released, and the final RC is scheduled for the following Monday. They described the recent upgrade from Gerrit v3.12 to v3.13 as the “easiest upgrade ever” with no reported issues so far; GerritHub.io is already migrated smoothly without problems.
bzlmod Timeline[SZ] confirmed that Thomas Draebing and Jacek are working on the migration to bzlmod.
[SZ] explained that bzlmod simplifies dependency management by making it easier to add
dependencies, similar to using Maven, and will eliminate the huge WORKSPACE file.
[LM] questioned whether updates to submit-requirements for library compliance
would be needed for the modules. [EK] suggested that the library compliance check could be
adapted later by modifying the submit requirement to check for additional files.
[LM] expressed concern that the bzlmod migration might cause a delay for the v3.13
release and suggested moving it to v3.14 if not merged by Friday or the following Monday.
[SZ] inquired about any potential issues with using bzlmod from a Google
perspective. [EK] indicated they were unaware of any issues, as nobody at Google had
looked at it yet, but noted that internally they use Blaze, the internal version of
Bazel. [SZ] stated that the migration to bzlmod is necessary because some features
currently used are deprecated in the next Bazel 8.x versions.
[LM] reported that the release process from RC2 to RC4 has been fully automated. They explained that the release change is now done by a pipeline robot, and the GPG key signature is also done by the robot, with the encrypted key. To ensure security, the passphrase for the GPG key is held by the release manager and not stored, preventing automatic builds if the box is compromised. Furthermore, [LM] described a new security measure to destroy Sonatype keys after the v3.13.0 release and recreate new ones for every subsequent release, eliminating the risk associated with long-term key storage, similar to an attack faced by npm maintainers.
[LM] provided an update on the transactionality issues (see Issue 440360427, Issue 450577969 and potentially many others in the past), mentioning that Dani is tackling some aspects. They highlighted that when Lucene fails, there are no logs generated; actually, Lucene does not log anything through Gerrit, because the logger is a NOOP. Dani is working on a change to configure Lucene logging and introduce an explicit “flush” method, as Lucene currently only uses auto-flash. [LM] explained that an explicit flash would allow for committing to a broker like Kafka immediately afterward, which is not possible with the current misalignment. [SZ] questioned if this only minimizes the probability of issues. [LM] clarified that the goal is to prevent the loss of index events by leveraging the broker’s message queue if the messages haven’t been committed, acting like a transaction log in a multi-site setup.
They concluded that a design document is needed for a future version to fully address the transactionality issue even without a Gerrit multi-site setup.
[LM] announced that the Gerrit Summit videos and presentations are now published online. [EK] mentioned watching one of the presentations from Martin. [LM] confirmed that the next meetup is scheduled in Munich in a couple of weeks, and [EK], Matthias, and Han-Wen will be attending.
[LM] shared that Skyler presented on JJ support for Gerrit, enabling users to clone a Gerrit project, work with JJ, and push changes without needing hooks.
[EK] questioned if this made their design document obsolete, as JJ now supports Gerrit Change-ID in the footer. [LM] noted that the change ID in the footer may not be sufficient if changes originate from other version control systems where the ID is in the header. [LM] strongly recommended watching Scott Chacon’s video on GitButler, describing its local UI as “really, really nice” and much better than GitHub’s interface.
They explained that GitButler works naturally with Gerrit as a client, automatically understanding how to interact with Gerrit for creating patch sets and amending changes. [LM] added that JJ is more suited for advanced users, while GitButler is for everyone, but noted that GitButler is a commercial product, whereas JJ is completely open source.
]]>This update covers key discussions, events, and future planning points discussed by the Gerrit community team, reflecting recent activities and upcoming initiatives.
The recent Gerrit User Summit was a great success, one of the best ones in over a decade, generating considerable enthusiasm and valuable discussion. We were particularly excited to welcome members of the broader Git ecosystem, including Patrick Steinhart from GitLab, Scott Chacon from GitButler and Skyler for the JJ project. Their presence fostered excellent cross-project conversations and highlighted areas for future collaboration.
We extend our sincere thanks to the OpenInfra Foundation for their generous support and for hosting the event, ensuring a smooth and productive gathering for all attendees.
You can access the full summary of the summit on the GerritForge blog.
Looking ahead, we are exploring new ways to expand community engagement and collaboration:
Luca suggested initiating early conversations with GitButler, Google, GitLab and other interested parties about jointly planning an even more integrated conference, reminiscent of the old GitTogether days for next year, where we could cover even more broadly the git ecosystem, even including the JJ community.
To encourage new contributions and onboard organizations like GitButler, Luca proposed a German-based company to host a Gerrit beginners hackathon in Berlin. Matthias has offered to check on providing a suitable room for the event but requires a confirmed date to proceed with logistics.
Matthias will also investigate the possibility of officially representing the Gerrit project at FOSDEM to raise visibility and connect with other open-source communities. The deadline for the call for stands is the 9th of November.
Mark your calendars! The next Gerrit community meetup will take place at the Google Munich office on November 19th in collaboration with the Google Cloud Developer Group. The event is already sold out on the GDG page, while there are still a few spots available on the meetup.com. Dani will send a formal announcement of the event to the mailing list next week.
Progress is continuing on the redesign of the Gerrit Code Review website. Nasser will commit to doing more reviews on the homepage mock-ups and development.
If you’re a frontend developer and would like to propose your own design feel free to reach out on discord or the mailing list.
A recurring point of discussion—and a notable observation from the OpenInfra attendees is that only a couple of people out of hundreds using Gerrit at the OpenInfra projects were aware that Diffy is the official Gerrit logo. This is a significant branding issue with out logo and its discoverability. We propose to start discussions again on improving the project logo to one that is more immediately recognizable and representative of the Gerrit code review tool.
]]>Next meeting: October 29, 2025
[LM] presented the Gerrit 3.13 release plan and discussed the risks of an NPM-like supply chain attack, the Gerrit User Summit, and the transactionality of Lucene. [EK] announced the open-sourcing of the Google MCP server for Gerrit and addressed JJ client-side support for Gerrit. [SZ] suggested implementing a durable event log for Lucene and rethinking the “transactionality” name for future developments.
[LM] presented the release plan for Gerrit 3.13, proposing an RC0 release on September 29th, followed by five RCs until November 3rd, with a release freeze and target release date of November 10th. [SZ] noted that SAP does not depend on these releases; also Google typically works on master. Nevertheless, most of the community works on stable releases, therefore cutting regular stable branches and release them it’s a general good practice for the rest of the Gerrit community.
[LM] provided an update on the Gerrit User Summit 2025, highlighting increased participation and new speakers like Patrick from GitLab and Scott Chacon, co-founder of GitHub. The summit will also include remote presenters and live streaming on GerritForge’s YouTube Channel, with talks covering topics like GitButler and JJ integration, and case studies from Qualcomm and NVIDIA.
[LM] raised concerns about the NPM supply chain attack and the learnings for improving the security of the Gerrit’s release process. [LM] suggested to move towards more automated release processes, similar to Google’s internal CI system, to minimize security vulnerabilities and assuring complete repeatibility of the releases from the source code.
Lastly, [LM] highlighted the need to use separate signing keys and short-lived Maven authentication tokens for publishing the release, so that any potential leak of credentials won’t impact the safety of the published artifacts.
[LM] discussed the issues of transactionality of the Gerrit indexes stored in Lucene (see Issue 450577969 and Issue 440360427). While the problem is rare, it has been exacerbated by the introduction of AI agents creating and abandoning changes, leading to increased concurrency.
[SZ] and [EK] suggested implementing a durable event log or queue for indexing to ensure eventual consistency and recoverability from failures, an approach Google already uses for their internal indexing system.
[SZ] took the initiative to start drafting a design document on the rewrite of the indexing subsystem in Gerrit, something that SAP is already planning to do with the split of the reindexing tasks to a separate service in their deployment.
[EK] announced that a team at Google received approval to open source the MCP server and will present during the GerritMeet on the 19th of November at Google HQ in Munich, with the code expected to be published by then. [EK] clarified that the Google team is not taking ownership of its maintenance, making it a community-driven effort. [LM] stated that GerritForge is willing to contribute to the project but clarified that support will follow Gerrit’s support process.
[EK] mentioned that JJ is working on supporting Gerrit change IDs natively, which has now been merged and presented at the Gerrit User Summit 2025. [LM] highlighted that a guide has been approved and merged into the JJ project to simplify integration. [LM] also noted that GerritForge plans to fully transition to JJ for client development and sees strong synergies with the JJ community.
[LM] stated that the project roadmap will be updated to reflect the v3.13 release and future plans. They anticipated that major game-changers for Gerrit in 2026 will be the integration of JJ and the MCP server, along with work being done at SAP. [SZ] suggested rethinking the “transactionality” in Gerrit and potentially transition to a micro-service based deployment for a future v4.0 release.
]]>| Date | Activity |
|---|---|
| Sep 29 | Create stable-3.13 branch, Release 3.13.0-rc0 |
| Oct 6 | Release 3.13.0-rc1 |
| Oct 13 | Release 3.13.0-rc2 |
| Oct 20 | Release 3.13.0-rc3 - Feature freeze deadline. |
| Oct 27 | Release 3.13.0-rc4 |
| Nov 3 | Release 3.13.0-rc5 - Release freeze |
| Nov 10 | Final release of 3.13.0 |
There are no official plans for Gerrit hackathon, however, the maintainers attending the Gerrit User Summit 2025, 17-19 October will be able to get together and work side-by-side at the release during the event.
We plan to use the Gatling e2e test framework for Git, developed by GerritForge and Ericsson to test the stability of the release on a production-like setup.
GerritForge, who is also offering Gerrit-as-a-Service on Google Cloud Marketplace, will be testing the scalability of Gerrit v3.13, particularly with medium to large-sized projects and in a multi-primary setup with Kubernetes on GKE.
Per the support policy mentioned in the project homepage, after 3.13.0 is released, 3.10.x will reach the end of life and will no longer be actively supported.
Support for 3.11.x and 3.12.x will continue as usual. Users of 3.10.x or earlier are recommended to upgrade to one of these versions.
]]>Participants: Edwin Kempin [EK], Luca Milanesio [LM], Saša Živkov [SZ]
Next meeting: September 24, 2025
A critical Gerrit migration to Bazel 8 is needed to fix compatibility issues with JGit. Gerritforge offered to lead the effort with Google providing reviews. The immediate next step is to add more details to the associated issue 303819949.
Two key community events were announced: a Git Mini Summit in Amsterdam on August 28th and a GerritMeet at Google’s Munich HQ on November 19th. The Munich event is notable as Google will unveil a new open-source MCP server, which generated significant interest.
The future of AI-powered code review was discussed, centered on the experimental “help me review” feature. Google confirmed ongoing internal development and welcomed collaboration to prevent duplicated work. A native chat functionality was also proposed to streamline AI integration in the future.
[LM] raised the issue of migrating Gerrit to Bazel mode, noting that JGit had already migrated to Bazel 8 and bzlmod, causing compatibility issues with Gerrit, which is still on Bazel 7.6.6 and relies on WORKSPACE support. [EK] confirmed that the migration effort is not yet on Google’s Gerrit Team backlog, as they rely on Blaze, which still supports WORKSPACE for the foreseeable future. [LM] suggested that Gerritforge Inc. could allocate the task for the effort through the compatibility approach (see https://bazel.build/external/migration), assuming that Google is available for reviews, because any modification to the dependencies requires an LC+1 from a Google maintainer. [SZ] suggested that Matthias Sohn would be a suitable person to help with this, and [EK] agreed that a summary should be added to the issue 303819949 detailing the work, pluses, minuses, and required involvement from Gerrit maintainers would be helpful to start the discussion and planning of the activity.
[LM] announced that Gerritforge, GitLab, GitButler and Google are sponsoring a new Git event in Europe, scheduled for August 28th in Amsterdam. [LM] explained that this “Git mini summit” was organized as a community-driven complement of Git Merge in the US for all of those who have travel restrictions or concerns to the USA. Their team plans to present their work on JGit optimization and performance improvement with Gerrit, GitLab, and GitHub Enterprise, thanks to the R&D work done by Gerritforge in 2024 and 2025 as part of the GHS product. [EK] mentioned that the Gerrit team is unlikely to participate in this community event; however, other Google members working on the Git Team will join.
[LM] announced that Florian from Google Cloud and Daniele from Gerritforge had agreed to organize a GerritMeet event at the Google EU HQ in Munich, with the date already set to November 19th, 2025. [LM] also mentioned that Google would be presenting a brand-new MCP server for Gerrit Code Review as a new Open-Source project on the Gerrit ecosystem. [EK] and [SZ] expressed interest in attending, especially since it is in Germany and relevant to their activities.
[SZ] inquired about the future of Gerrit’s experimental “help me review” AI button, which their users have been exposing internally. [EK] confirmed that there are many internal discussions about this feature and suggested reaching out to Milutin, who is driving Google’s AI efforts around Gerrit, who has started implementing the frontend UI based on a fake backend. [EK] welcomed help from [SZ] with this effort, which would prevent duplicated work. [LM] noted that while the current AI suggestions are about 20-30% useful, integrating a native chat functionality within Gerrit could make existing AI code review plugins (chatgpt-code-review and ai-code-review) less relevant in the future, and they are happy to support Google’s AI endeavor once it’s fully open-sourced.
]]>Participants: Edwin Kempin [EK], Luca Milanesio [LM], Saša Živkov [SZ]
Next meeting: July 30, 2025
[LM] provided a status update of the issues with packed-refs and the status of reftable testing, including pending issues with C Git. For the forthcoming Gerrit User Summit 2025, there is interest in AI features for Gerrit Review which will be reported by [LM] in his proposed talk.
[SZ] detailed the current status of the packed-refs issues and their mitigation
strategy for the backdraft file issue, which involves a script to repair everything
using a global-refdb maintaining backups.
[LM] mentioned that their team has observed other strange issues related to concurrency between deletion of refs and packing of the refs, including reverted refs during repacking and the return of removed refs. A bug in the locking system for deleting refs was identified and fixed by Dani.
[LM] also highlighted a POSIX compatibility issues with some specific NFS implementation, where data written to a file and closed was not immediately visible to another node after performing the open of the file after the closing on the other node.
reftable test status[LM] provided a positive update on extensive testing with reftable, noting that a problem
involving an unexpected closed file descriptor has been identified and a straightforward
fix is expected. They suggested adding [SZ] as a reviewer, as a stable reftable could be
a much better alternative to packed-refs due to scalability issues.
[LM] emphasized the significant problem with deleting refs in packed-refs, which requires
rewriting the entire file. Testing of reftable is also being done on NFS.
[LM] mentioned that C Git still has many issues with regards to reftable, including corruption
of the refs, and expressed a need to identify specific test cases.
Regarding the Gerrit User Summit in Paris, [SZ] stated that their initial plan to organize a hackathon there faced issues, and they will recheck the possibility of at least one or two team members attending just for the summit.
[LM] highlighted the ai-features topic on Gerrit Review related to AI features. [EK] clarified that their AI focus is currently internal for Googlers. [SZ] had also seen the feature, noting that the AI prompt appeared self-contained. [SZ] expressed interest in the Gerrit community consolidating ideas for AI integrations, mentioning a question from SAP about AI-based automation.
]]>