Forgejo monthly update - June 2024

The monthly report is meant to provide a good overview of what has changed in Forgejo in the past month. If you would like to help, please get in touch in the chatroom or participate in the ongoing discussions.

The User Research effort that gained momentum two months ago continues with a new round of user testing sessions. It is key to collect evidence about what Forgejo users need, a requirement to build a roadmap and reduce the growing backlog of bug reports and feature requests.

Building blocks for both ActivityPub federation and data portability improvements were merged into the codebase. They are not yet used for any user visible feature but they are a stepping stone. Their implementation was made significantly easier by the hard fork because they can rely on a codebase that is better tested.

User Research

Discussions began on a new workflow for design work and feature requests. Users are encouraged to describe the problem rather than the solution. Feature requests typically consist of the description of a solution. However, often there are multiple solutions to one problem, and there are multiple problems with one solution.

New feature requests are not ready to implement: they are investigated first, similar to how new bugs are triaged. A research and design process can be established, similar to what was done for the summary tab for repositories and bootstrap actual process for changes in Forgejo. This adds a step between what user needs and development, but since the backlog of feature requests is growing anyway, it may not be an issue. On the contrary: merging similar feature requests together can reduce the backlog of open feature requests and only the most valuable changes are implemented.

A new round of user testing sessions was conducted from 26 June to 28 June. It is based on an interview script improved from the one that was already used in April 2024 during the first round.


Notable improvements:

Read more in the pull requests.

Standard formats and protocols

Forgejo supports third party software and services that use standards. For instance it relies on SQL for interactions with databases, HTTP, HTML and JavaScript for web interactions. As an exception when the software or service is available under a Free Software license, the absence of standardized communication protocol is not a requirement, for instance for LevelDB.

It is not an easy goal to achieve because software publishers keep deviating from standards or change the license of their software to no longer be Free Software.

  • Microsoft SQL Server deviates from the SQL standard in ways that required special treatment and the decision was made two months ago to no longer include such specific adjustments.
  • Redis used to be Free Software, but the newer versions are not. The protocol is not standard but alternative servers exist and Forgejo is now tested to work with them. Only the older Free Software version of Redis will continue to be supported, but the proprietary versions will not.
  • Safari is expected to support HTML, HTTP & JavaScript in the same way other browsers do, but fails some tests. The approach chosen was to skip Safari testing instead of finding a workaround. An effort is generally made to workaround the non-conformant behavior of Free Software Web browsers. But, for reasons similar to MSSQL, such an effort is not sustainable for proprietary Web browsers.

Other discussions happened on integrating Forgejo with third party software or services that are not Free Software and do not comply with a standard format or protocol (Azure Blob Storage, CockroachDB and Friendly Captcha).

Data portability

The Friendly Forge Format (F3) is designed to improve data portability and make it possible to mirror software projects from one forge to another using a standard format. The v2.0.0 was published in June 2024 and is the first stable version. It is implemented in a Go package that can be used as a reference. A native driver for Forgejo was merged so that it can be used, for instance, to transport data when an ActivityPub message is received. Or as an alternate implementation for the migration code.

Read more in F3 related issues and pull requests.


The pull request to implement federated repository stars was merged. The feature allows you to define following repositories such as origin of mirrors or forks. If then the mirror or fork gets a star by someone, the origin repository will also get a star via federated ActivityPub like activity. Only the star activity is federated, the unstar activity is not federated and the user interface is not available yet.

A new federation suite was added to the end-to-end tests. It is very basic but the first of its kind. Launching two Forgejo instances that star each other via ActivityPub.

Although GitLab federation efforts are now on pause it includes an experimental implementation of the ActivityPub building blocks which is roughly at the same stage as Forgejo. Support for launching a GitLab instance was added to the end-to-end tests. This will eventually allow to play scenarios in which GitLab and Forgejo can communicate in a controlled environment. And in the short term to apply minimal testing on each of them independently, for instance with activitypub-testing.

Read more in the June 2024 report.

UI team

The UI team was created and has three members.

Before engaging in more ambitious goals, they started to care for the day to day chores that keep Forgejo releases going:

  • Implementing and reviewing new UI features which is particularly challenging because the test coverage of the Web UI is still very low.
  • Backporting bug fixes to the stable versions (7.0.4 & 7.0.5).
  • Reviewing upgrades of JavaScript packages and other dependencies that are used to build the Web UI. It would be relatively easy if every package consistently complied with semantic versioning and published descriptive release notes. But the norm is rather the opposite and each potential upgrade requires a fair amount of scrutiny.

An experiment to hire a freelance to work on improving the JavaScript test coverage was conducted to figure out if it leads to results that are worth the effort. It was interrupted when evidence surfaced that the work was almost identical to what an AI would produce.


The machine added last month is now in production and stable. It did not go smoothly because the hardware provisioned turned out to be unreliable and crashed frequently. The devops team spent hours over a period of a week to figure out the root cause and stabilize it. This was not transparent to Forgejo contributors because the CI stopped working half a dozen time and stayed down during a few hours. But nothing was lost and the downtime was kept to a minimum. It happened in between releases and did not disrupt the release process.

The upside of these troubles was to check that every aspect of the disaster recovery scenario work as it should, including loosing all disks on the machine. The defective hardware was not stabilized, it could not. It turned out that all machines with the same motherboard were similarly flawed. Hetzner acknowledged their defective product range, apologized, reimbursed the costs and is in the process of changing their Q&A to include the test script that was provided to demonstrate the problem.


Forgejo v7.0.4 (fixing vulnerabilities) was released. The security fix it contains was also backported and released as Forgejo v1.21.11-2.

There now is a stronger requirement for testing for all backports to a stable release. The bug fixes originating from Gitea were previously merged even when they were not covered by any test. Tests are now added when the fix is worth the effort. The test itself is implemented in the development branch and the commit that contains the fix is cherry-picked with the backport of the test to demonstrate it works as it should.

A discussion regarding the Forgejo v8.0.0 feature freeze an attempt to better define the requirements imposed during such a period and the need to fix bugs when the infrastructure to write tests is missing.

Dependency Management

Caring for the hundreds of Forgejo dependencies has been a recurring activity since the beginning of the project back in 2022. When the hard fork happened early 2024 Forgejo gained the freedom to decide on each of them and began to organize accordingly. Gitea was first and using the dedicated tool that was developed to sort the commits of interest became a comfortable weekly routine.

The backlog of all other dependencies was more challenging. A dependency dashboard was setup and started with a large backlog. Only in June 2024 was it cleared, months later. Pull requests with upgrades are now dealt with daily and diligently so they do not pile up again.

The method to analyze each of them was documented and heavily relies on the dependency specifications to keep the workload to a minimum. For instance it can arrange for updates to only be proposed every three months for CI tooling while it immediately proposes an upgrade if has an impact on security.

Helm chart

The Forgejo helm chart had two patch updates, one for 7.0.1 which depends on Forgejo v7.0.4 and another for 5.1.2 which depends on Forgejo v1.21.11-2.

The Forgejo helm team was created was created and two members joined.


4 batches of updates were merged containing total of 937 new translations and 518 improvements. Some improvements were made to the process of localization management. One of which is that now backporting of translation updates to stable versions can happen in batches before releases are published instead of weekly.

No new team applications were submitted or accepted this month. Some languages are not actively maintained currently. View completeness of translations in our project on Codeberg Translate and Learn how to help.


There is a new funding opportunity for Sovereign Tech Fund and a grant application is being drafted. Its scope is similar to OTF and most of the material can be re-used.

The grant proposal submitted 16 May for the Free and Open Source Software Sustainability Fund was declined. In a newsletter OTF announced that they received 80 applications.

A reply was expected for the NLnet grant application submitted 1 April but was further delayed and is expected in July.


There has been very few minor moderation incident (spam or trolls) and one time warning. This is significantly less than the past month where there were bursts of unsolicited activity that sometime required daily intervention. Even the smallest interventions were logged in accordance to the moderation process.

A concern was raised regarding the lack of answer of the moderation team despite numerous attempts over a period of months. There has been no major incident so far but it may be wise to take steps for Forgejo to be in a space where it is possible to reach the moderation team before it happens.

We Forge

Forgejo is a community of people who contribute in an inclusive environment. We forge on an equal footing, by reporting a bug, voicing an idea in the chatroom or implementing a new feature. The following list of contributors is meant to reflect this diversity and acknowledge all contributions since the last monthly report was published. If you are missing, please ask for an update.

A minority of Forgejo contributors earn a living by implementing the roadmap co-created by the Forgejo community, see the sustainability repository for the details.