Improve how we vendor kernels that have upstreams (reduce divergence / maintenance burden)

[moon-bot-app]

Problem

Today, when we vendor a kernel that has an upstream (e.g. NATTEN huggingface/kernels-community#1031, which adds 431 files), we essentially copy the upstream source into kernels-community and then make many changes on top: fixing paths, restructuring files, adding bindings, etc.

This leaves us in a state where:

• It's hard to tell whether a given line comes from upstream or is a change we made.
• When upstream changes, we have to figure out where that change maps in our edited/restructured kernel.
• Over time the port naturally diverges from upstream, increasing our maintenance burden.

This is especially relevant for brand-new kernels (like NATTEN) where we expect upstream to keep changing.

Idea

Best case: have an additive-only patch set that converts an upstream repo into an HF kernel. When upstream changes, we'd pull upstream and reapply our patches. Benefits:

• We could make statements like "our kernel is as up to date as upstream's last commit."
• Lowers the barrier to entry — existing kernel authors often don't want to restructure their whole repo but would like to benefit from the kernels project.

Open questions / discussion

• How is this meaningfully different from the current workflow, and does it hold up when the patch itself introduces small-but-numerous changes?
• We've been using an agent-driven approach (à la the AGENT.md in kernels-community) for the restructuring changes, and it seems to work fairly reliably — does that already lower the cognitive load enough, or is a formal patch-set approach still worth it?

Filing this to track the discussion started in Slack.

---

Requested by Sayak Paul - Slack thread - Agent trace

[danieldk]

Patch sets are going to break all the time (not apply cleanly) though. E.g., we typically have to change all the imports to relative imports. Just an upstream reordering (let alone added imports, etc.) will break the parch set. It gets even worse because we have to move files around, etc., so pretty much all unified diffs (accepted by patch) will completely remove a file and add a new one. I have found that with good agent instructions, some kernels can be updated in a few minutes.

Best is to convince people to move to kernel-builder of course.

[danieldk]

I wonder if we should make a program that does some of the transformations using ASTs, such as relativizing imports, rewrite op definitions, etc. We could also give it a mapping of source file locations. I am not sure how reliable it will be in practice, but it may be worth trying? It would be similar to what we ask agents now, but it would actually be deterministic. I think even automating a subset of the transformations in that we could already be useful, because we could tell the agent to use it and then validate the results.

[sayakpaul]

I have found that with good agent instructions, some kernels can be updated in a few minutes.

I completely agree and that has been the experience for me, as well. I really cannot think of a better workflow here.

I wonder if we should make a program that does some of the transformations using ASTs, such as relativizing imports, rewrite op definitions, etc. We could also give it a mapping of source file locations. I am not sure how reliable it will be in practice, but it may be worth trying? It would be similar to what we ask agents now, but it would actually be deterministic. I think even automating a subset of the transformations in that we could already be useful, because we could tell the agent to use it and then validate the results.

For things like where it's relatively easier to verify (relative paths, ops registrations, etc.), I think we could definitely have a utility and let an agent use it and also verify. This way, we will very likely also save some token consumption.