Continuous packaging for your patches.
sexy robot AI voice: QuiltOps is a platform for pushing the envelope of distributed development back towards the user. Everyone can fork. Almost nobody1 can maintain a fork. QuiltOps fixes that.
but seriously, QuiltOps is an infrastructure tool for maintaining user customized patches against upstream Debian packages.
You write patches. QuiltOps builds them, publishes them to a personal apt repo, and keeps them building against new upstream releases automatically.
It is not an AI product. You write the patches however you want. Crafted by hand, with AI, or by bribing someone. This system exists to ensure your patches stay deployed alongside upstream code automatically and to give a good framework for doing it.
In some ways I consider this the antithesis of new-fangled "skip the lessons we learned and invent our own package manager" I see with NPM and others. Instead we are going to lean into, and respect and trust our beloved system maintainers, and instead of having boatloads of binaries in /home/, we're gonna ship them like real packages.
My bet: AI is going to make software much more horizontal. Less cathederal and more bazaar. It's something a lot more will people actually do.
Hey Claude - can you update xpdf to support pdf2teletubby?
Sure, theres the patch.
Right now, programming is rapidly becoming not expert work. Soon we could all be running (i think this unironically) practically our own distros if we want. Total customization of the stack.
I really feel that one positive thing AI can do is drive labor costs down enough to allow personal choice in the software we use. We have open source software, but it's channelized and controlled by a few companies who fund projects! That might change too!
AI can simply One Shot a lot of small problems i have. Like reading unfamiliar codebases, finding the relevant function, and writing the delta. The gap between "I want bash to do X" and "here's a patch" is shrinking fast. When that gap closes, a lot more people are going to start customizing their software - but we don't have a great wrapper for it yet.
The part that doesn't get easier is everything after. How many 'forks' exist on github but people havent had time to maintain, or worse, are being used in production with bugs? How much code have we lost out because of that? Do forks really help us? I don't know. Does everyone want to use shitlab? I don't know.
Building the package. Getting it on your machine or out to the fleet. Keeping it there when upstream ships a security fix.
That's an infrastructure problem, not an AI problem I needed a way to solve it now
QuiltOps is that little bit of software infrastructure i need . built now, for the world where i am right about my bet.
Patches, quilt, apt repos, it's all already there for a discerning individual with the time to play. This isn't novel technology. QuiltOps is to patches what GitHub is to git: the same underlying thing, minus the part where you spend your afternoon writing glue scripts and repenting to mechanical overlords.
I keep... hundreds of patches around. Hundreds of source repos that aren't even patches, just git checkouts. I use this software every day. Over the years the list has gotten enormous. quilt is great, actually, so much of this already exists, serving repos, building packages, getting packages from upstream. it's stuff that exists in bits and pieces. Launchpad's been around forever. There's very competent tooling from debian for building packages, now i want the full package cycle.
So my goal with this is really selfish, part of my bet coming true, that i can write a standalone service for myself just to manage my own patches... but why not share it? or make it 'realer'. Maybe you will have a patch you manage on quiltops of my quiltops package.
One inspiring source for me is /n/contrib. After Plan9 gained a following, or maybe before, but after there stopped being upstream, the plan9 universe folded and folded. There were distributions of One (Ants), distributions of some (9front), distributions of none (9legacy?)... I don't know but the point is you had a place you could share your patches and code with other people but everyone was kind of manually pulling patches in or doing what they wanted. Plan9's code base is small enough that you can hack on it with a bit of C and shell skills (rc) and get very far. Most plan9 setups I know are part of a diaspora, and almost all are customized in one way or another.
Another source of inspiration are the dedicated individuals and maintainers who we owe our lives and at least some of our hearts to. I am inspired by Launchpad, AUR user packages, the OpenSUSE build system, Copr, etc.
Portage basically has a very similar feature for user patches, but hey - thats gentoo for you. I want that but for binary packages and automated builds and some tooling. thats all!
Should we start writing tons of AI generated, or user generated, or whatever, patches for other systems, it might be quite nice if we could share them. I think quiltops could be used to do that if we can share our patches into O.P.P. its like /n/contrib but Other.Peoples.Patches. Anyway its kind of an idea of where this could go. You could pull other patch sets in and roll them on top of your own, and still be getting upstream changes
without quiltops:
with quiltops:
I worked at a place that used debian on a fleet of servers. We also had many packages we wrote and maintained and distributed. But we also had some that were upstream+patches. With the rate of 0days hitting, I feel like this type of tooling could be useful. I also know hosting your own debian repos can be a slight pain in the but and you end up writing plenty of glue to get that up, running, and lights on.
When you run a custom package today, you are making a silent tradeoff: your modification or upstream's fixes. Most people quietly fall behind.
QuiltOps watches the Debian package index. When upstream ships a new version — a CVE patch, a bug fix, anything — QuiltOps rebuilds your package against it automatically.
If the patch applies cleanly, you hear nothing. Your apt repo just has a new version. If it does not apply, you get an email with the full build log. Your old version stays live until the new one builds clean.
Day 0 you push 0001-sqlite-history.patch for bash
QuiltOps builds bash_5.2-3+qo1, publishes to your apt repo
Day 83 Debian ships bash 5.2-4 (CVE fix)
QuiltOps detects new version, enqueues rebuild automatically
Day 83 patch applied clean, bash_5.2-4+qo1 published
+5min you hear nothing; apt upgrade gets you the fix
qo push triggers a build. The server fetches upstream, applies your patches, and runs dpkg-buildpackage.$ qo init -> created quiltops.yml, patches/, CLAUDE.md $ qo build bash -> fetching bash 5.2-3 from bookworm... -> applying 0001-sqlite-history.patch... -> built bash_5.2-3+qo1_amd64.deb $ qo install bash -> dpkg -i bash_5.2-3+qo1_amd64.deb $ qo push -> pushed . build queued on quiltops.dev $ qo status bash [ok] 5.2-3 built 2h ago i3 [!!] 4.3-2 patch failed -- run 'qo log i3' to see why xpdf [ok] 3.04-3 built 1d ago
packages/
bash/
quiltops.yml # upstream source, suite, patch list
patches/
0001-sqlite-history.patch
i3/
quiltops.yml
patches/
0001-ewmh-desktop-window-type.patch
quiltops.yml # repo-level config
CLAUDE.md # AI context for patch rebasing
The starter repo ships a CLAUDE.md that gives >your AI tools< enough context to fix a failed patch immediately. No I dont have any funding and im not putting my credit card on anthropic for you. Your inference needed — you bring your own AI.
qo push is a git push in a trench coat.| Plan | Price | Notes |
|---|---|---|
| Self-Hosted | Free | Full source, bring your own compute, unlimited packages |
| Hosted | Free? | I can't imagine someone would pay for this! maybe! |
| Team (hosted) | TBD | Would anyone actually pay for this?2 If so, email me. |
quiltops.dev — source — IRC: #quiltops on libera.chat