QuiltOps - continuous packaging for your patches

QuiltOps

Continuous packaging for your patches.

About

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<br>customized patches against upstream Debian packages.

You write patches. QuiltOps builds them, publishes them to a<br>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<br>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: Software Goes Fully Horizontal

My bet: AI is going to make software much more horizontal. Less cathederal and more bazaar. It's something<br>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<br>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<br>enough to allow personal choice in the software we use. We have open source software, but it's<br>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<br>function, and writing the delta. The gap between "I want bash to do X" and<br>"here's a patch" is shrinking fast. When that gap closes, a lot more people are<br>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<br>github but people havent had time to maintain, or worse, are being used in<br>production with bugs? How much code have we lost out because of that? Do forks<br>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<br>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.

Before Today

Patches, quilt, apt repos, it's all already there for a discerning individual<br>with the time to play. This isn't novel technology. QuiltOps is to patches what<br>GitHub is to git: the same underlying thing, minus the part where you spend your<br>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.<br>Over the years the list has gotten enormous. quilt is great, actually, so much of this already exists, serving repos, building packages, getting packages<br>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<br>write a standalone service for myself just to manage my own patches... but why<br>not share it? or make it 'realer'. Maybe you will have a patch you manage on<br>quiltops of my quiltops package.

Before Today Deux

One inspiring source for me is /n/contrib. After Plan9 gained a following, or<br>maybe before, but after there stopped being upstream, the plan9 universe folded<br>and folded. There were distributions of One (Ants), distributions of some<br>(9front), distributions of none (9legacy?)... I don't know but the point is you had a place<br>you could share your patches and code with other people but everyone was kind of manually pulling<br>patches in or doing what they wanted. Plan9's code base is small enough that you can hack on it with a bit<br>of C and shell skills (rc) and get very far. Most plan9 setups I know are part of a diaspora, and almost all are<br>customized in one way or another.

Another source of inspiration are the dedicated individuals and maintainers who<br>we owe our lives and at least some of our hearts to. I am inspired by Launchpad,<br>AUR user packages, the OpenSUSE build system, Copr, etc.

Portage basically has a very similar feature for user patches, but hey - thats<br>gentoo for you. I want that but for...