Jian Peng venit, vidit, dixit 2026-01-14 15:21:22: > Follow-up on automation. > Thanks again for the incredible insights so far. > > I have one follow-up question regarding tool design, especially in the > context of recent advancements in LLMs: > > If we were to develop an automated (or semi-automated) patch migration tool, > should we treat the "Original Source Repository/Context" as a mandatory input?
What is the aim of the tool? Migrate patches from one downstream to another? From upstream to downstream? Between branches? > The Dilemma: From an algorithm perspective, having the original source code > (pre-patch state) definitely helps the model understand the semantic changes > better. If you cherry-pick or rebase patches between different branches in the same repo you face similar challenges already: A patch may apply cleanly but still incorretly in the context of the different branch. E.g. git tries to help by finding a merge-base and "understanding" which changes were made on which branch but does not analyze code. A user can resolve a conflict and record the resolution (rerere), which git can reuse. Are you thinking of an AI enhanced rebase/cherry-pick supporter? That seems useful independent of the packaging context, but depends on the AI's understanding of the code. > The Usability Concern: However, based on this discussion, "hunting down" that > exact original context seems to be a non-trivial task that requires manual > effort or specific skills. > > My question to you: If a tool required you to manually provide the "Original > Source URL/Commit SHA" for every third-party patch you wanted to port, would > that friction be too high? Would you consider that a "deal-breaker" for using > such a tool? > > Or should a practical tool strive to work like an experienced packager (as > Michael described)—inferring the logic primarily from the patch file + the > target codebase, treating the "original source context" as an optional luxury? > > I’m trying to determine if "Dependency on Original Source" is a feature or a > usability bug for real-world maintainers. I'm still not sure what's the distro maintenance part here, or whether it's general change management. A tool which identifies potential "original source contexts" could be helpful. It could start from identifying source trees to which a patch applies cleanly (textually), which does not even require an understanding of the code. Michael -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
