What Influenced Your AI LLM Policy

Push your tree/commit to a branch in your fork;

Open a merge request by following the link GitLab provided during the push;

Wait for the CI results, then address failures;

Wait for review comments, then address them;

Once the code is deemed ready by a trusted developer, it will be merged.

Due to an influx of spam, Freedesktop.org had to impose restrictions on new accounts.

Please see this wiki page for instructions on how to get full permissions.

Due to serious abuse of Freedesktop’s testing infrastructure (details), the use of the GitLab CI on freedesktop.org got restricted. Only group members can trigger pipelines, everyone else needs the pipeline manually triggered by an existing group member. See Freedesktop’s wiki for more details and possible remediation.

You may however use your CI-tron-based gateway to run your tests by exposing it in your fork. This can be achieved by:

Obtaining a runner registration project token;

Adding it to your /config/mars_db.yaml file (syntax:);

Setting the following variables in your project’s CI variables:

AARCH64_RUNNER_TAG_ARCH (default: aarch64): Leave empty or cpu:arch:aarch64 if you also have an amd64 runner

AARCH64_RUNNER_TAG_EXTRA (default: ‘’): CI-gateway

AMD64_RUNNER_TAG_ARCH (default: ‘’): Leave empty or cpu:arch:x86_64 if you also have an aarch64 runner

AMD64_RUNNER_TAG_EXTRA (default: ‘’): CI-gateway

Disabling the use of shared runners in the project.

The decision was primarily taken on ethical grounds:

Why reward the bad actors who have been consistently DDoS’ing our Freedesktop.org infrastructure?

Why spend our limited time interacting with someone else’s machine when we could be training real people who could become future contributors?

Why give legitimacy to the tools that are breaking the social contracts of the free software movement, as defined by their software licenses, thus allowing LLM users to effectively bypass FOSS usage conditions?

While these are political stances, the pragmatic reason is that AI/LLM contributions are a risk for the future maintainability of the project:

Why risk eroding the core-developers’ understanding of the whole system by outsourcing part of the design?

Why make the the quick-and-easy brute force solution practical when we could take the time to research the problem and find a more maintainable fix?

Why depend on an external service that we have no control over when it can: regress, price us out, revoke our access, or be weaponized to sabotage our project?

Why risk accidentally introducing code released by another open source project using an incompatible license?

We understand that you may not have the time needed to adhere to these ideals. We would thus kindly ask you to open an issue using your own words rather than a merge request: We would rather implement something from scratch rather than reviewing the output of your AI/LLM.

© Copyright 2023-2025, Valve Corporation.