The private beta, as it stands

Build 0.1.0-beta+622be8881587, 13 September 2026. The footer of every page names the build you are on.

What the forge is

quarry serves fossil repositories. A repository here is a fossil repository — you can clone it with fossil, and everything the forge records (tickets, forum threads, landings, technotes like this one) is an ordinary fossil artifact, readable by a stock fossil client. zit is the engine underneath; it is what makes the forge fast on repositories the size of sqlite and tcl.

New since the 7 September build

• Repositories have owners. Any account can create one, and the creator holds it. Ownership is recorded rather than inferred from who happens to hold a capability letter, which is what makes handing a repository over — or destroying it — something the forge can reason about. Destroying or un-serving a repository now belongs to its owner: an admin grant lets somebody help maintain a project, not end it.
• Teams. A team is a shared namespace with its own members and its own page. A team holds the path a repository appears under, never the repository itself, so dissolving a team can never put anybody's code at risk — the repositories simply appear under their owners again. Membership carries a floor on every repository under the team, and a member can choose not to be listed publicly.
• A forge can supply the storage. A repository with no bucket of its own now uses the forge's, if the forge binds one, so somebody standing quarry up for their friends need not send each of them to open an account with a storage provider first. This forge deliberately supplies none — every repository here binds its own — and a repository's settings page says which it is using.
• Attachments. Bring your own bucket: the bytes go to S3 or R2 that you control and the forge keeps a content-addressed stub. Paste or drop a file into any composer.
• Email works in both directions. Notifications and account mail send, an address is yours to set and change from your own account page, proved by a code sent to the new address, and you can reply to a notification by email and have it land as a post.
• Your own account page gathers your addresses, sessions, devices, notification preferences and the repositories you own in one place.
• Private repositories actually work. A private repository was reachable by nobody but the API — the pages never learned who was asking, so a private repository was invisible to its own owner. Fixed.
• Stacked landings can be recovered. When the branch below yours lands on its own, the record can be pointed at a new target from the page instead of only from a shell.

Mirrors

Nineteen projects are mirrored and kept current, so there is real history to search from day one: fossil, fossil-forum, libfossil, sqlite, libspatialite, lumosql, tcl, tk, tcllib, tklib, wapp, althttpd, pikchr, sqlar, docsrc, freexl, readosm, spatialite-tools and zit. They are read-only copies, refreshed on a schedule, and they belong to the forge rather than to any account.

Known gaps

These are real and worth knowing before you rely on something.

• Paths are still flat. A repository lives at /r/name, one global pool of names, even though it now has an owner and possibly a team. Namespaced paths are the next change; every repository URL is already built in one place so that it can be one change rather than three hundred.
• A site admin still passes every gate. The ownership model says the operator administers the forge and not the repositories under it. That is a design position, not an enforced one: the setup capability answers yes to any letter, so an operator can still reach anything. Where ownership is enforced today, it is enforced against other members, not against the operator.
• Nothing an operator does leaves a receipt. There is no audit record an owner can read. Operator power here is narrower than on other forges and still invisible, which is the half that would make it different rather than merely smaller.
• You bring the storage, not yet the rest. Attachments already live in your own bucket. Runners and a notification plane of your own are the intended shape and are not built, so CI and mail are the forge's.
• No pull-request-style review across forks yet — landings assume a branch in the same repository.
• CI failures recorded before 13 September 2026 may not be failures. A run that quarry superseded — which it does whenever a newer check-in lands on the same branch — was recorded as a failure on the check-in it belonged to. Of the runs still on record when this was found, 36 had been superseded against 10 that actually failed, so most red marks in older CI history describe a run that was stopped rather than one that broke. The behaviour is fixed; the tags already written are ordinary fossil artifacts that have been cloned and are left as they are rather than edited out of history.
• A deploy briefly takes the busiest repository offline. Repositories register in name order after a restart, so for about twenty seconds quarry itself answers "starting, try again" to clones and pushes. It says so now rather than claiming the repository does not exist.

Reporting a problem

The bug icon in the header opens a ticket on the forge's own tracker, filled in with the build and the page you were on. That is the fastest route; it lands where the work happens.