Governance

The maintainers

Read live from the pool, which read factory/MAINTAINERS.toml on main .

We do not use what you built, we learn from it

A contributor uses exactly the tools a maintainer uses — the same signed worker image, the same PKGBUILD conventions, namcap, the same build — to produce a package that respects the packaging practices, is checked for quality and is safer for users. An AI agent may help: nobody knows better than the author how their software should be compiled and packaged, and an agent turns that knowledge into a recipe faster. The agent's key is the contributor's, on their machine; the project runs no agent for them.

Nothing the contributor built is ever used — not the package, not the recipe. The maintainer does not trust it and must not. What they have in front of them is not "some software, go package it" — it is a recipe that already built, its log, its manifest, the gate's transcript, the second agent's audit, the corrections made along the way. Evidence. A maintainer (never the owner) reads it and has the project build the package again: on a worker the project trusts, with the project's agent, which gets the request and that evidence as the lesson and writes the project's own recipe from the project's sources — through the same gate, staged like any build, installed by a real pacman in the lab (the trial), its evidence on the record. Then a maintainer approves the project's build, and only that goes into the pool, signed. The pool enforces the line: a contributor's build cannot be approved (the API says so), a worker refuses to start from a staged artifact, and the project's build carries review:<task> — where it learned, never what it copied.

Zero trust between people, shared knowledge between them. Users get a package at least two different people stood behind — the contributor who made it work, the maintainer who had it built again and attested it — built twice, on two workers, by two agents, and never the first one.

The second agent. The contributor's agent, if any, wrote the recipe; the maintainer's side has one too. When a build is staged the pool queues an audit — a job a review worker takes only if its owner set an agent key. It reads the same evidence the maintainer will — the PKGBUILD, the build log, the .PKGINFO — asks its model for a structured review (supply chain, security, packaging practice, correctness against the log, licence) and attaches audit.json and audit.md to the evidence. Review shows the verdict next to the build: ok, warn (approve with the findings in mind), block (do not approve as is). Evidence, never a decision: nothing in the pool acts on it, the maintainer does. The builder cannot write those two files, the audit cannot write anything else, and a build decided before the audit ran cancels it. No review worker with a key, no audit: the column says waiting.

What each role does

Categories, not groups

There are no groups: no package belongs to an area whose maintainers own it, and no maintainer reviews only a part of the pool. What a package is about — for a person browsing — is its category, one of a fixed list: terminal, editors, development, browsers, communication, media, graphics, office, games, system, networking, security, fonts, themes, libraries, other.

Becoming a maintainer

Workers, compute and agents

Bumps and packages nobody builds

A new upstream release of an approved package is built the way the first version was — on the owner's worker, as evidence a maintainer reviews. Once a day the pool queues that build (bump:<task>@<tag>: the contributor's staged PKGBUILD with pkgver moved to the tag; evidence again, never the product). The owner's worker has 14 days; after that any shared worker may build it. 30 days without a build and the package is unmaintained: no more bumps until its owner builds again — or someone else requests the name and takes it over, the package still served until their build is decided; a maintainer who removes the registration takes the package out of every ring with it, on the record. There is no other path: nothing about a package goes through a pull request.

Blocking

The brake. It is on the Review page, The brake, and in the API; it takes a maintainer and a reason, and the reason is what the record and the contributor see.

The record and the score

Role changes are role lines in the journal, approvals are rows a maintainer signed with their login, trust decisions are trust lines, blocks and their lifting are signed records in the public bucket. The file's history on GitHub is the history of who decided what.

Track record. A profile sums that record, so it says how much work a person has done here — not who they are. As a contributor: distinct packages a maintainer let in, builds that produced evidence, of which bumps, builds their workers did for other people, rejections. As a maintainer: approvals, rejections, and approvals whose project build then failed. One number, so that the formula is public and dull: 3·let in + staged + bumps + for others − 2·rejected + 2·approvals + rejections − 3·builds failed. No rank, no badge, no threshold; becoming a maintainer is still a pull request another maintainer approves, with this record as one thing they look at.