Multi-agent framework for GStreamer patch migration
Port LG's ~4,000 downstream GStreamer patches from 1.24 to 1.28, a job that usually takes about ten person-months.
- downstream patches
- ~4,000
- needed a human to resolve
- ~46
- person-months
- 10 → 1
- GStreamer versions
- 1.24 → 1.28
Context
LG carries a long series of downstream patches on top of GStreamer, the media framework behind TV playback. Every upstream upgrade means rebasing that whole series: here, from 1.24.10 to 1.28.4.
Done by hand, a migration like this conventionally takes about ten person-months of careful conflict resolution and re-testing.
What I built
- A multi-agent orchestrator on Amazon Kiro that ports the patch series one patch at a time.
- Per-patch pipelines of specialised agents for conflict detection, API-compatibility analysis, semantic auditing, blast-radius analysis, conflict resolution and test verification.
- A deep patch analyser that produced a detailed analysis of all ~4,000 patches, stored in a per-patch artifact store keyed by commit SHA and fed to the agents as grounded input during the rebase.
- Retrieval-augmented (RAG) memory plus git rerere, so conflicts resolved once are reused automatically in future migrations.
Outcome
- About 4,000 patches migrated. Only about 46 needed a person to resolve their conflicts.
- The migration finished in about one person-month instead of ten.
- Recorded resolutions carry forward, so the next upgrade starts from what this one learned.