Dear Fedora Maintainers and Packagers,
I am currently investigating the complexity of patch management workflows
across different Linux distributions, specifically focusing on the challenges
of porting patches between versions.
I’m writing to ask about a specific "pain point" regarding source code context,
and I’m curious if my observation matches your daily reality.
The Context: There is a common assumption in academic research that for any
given patch, the "original source context" (i.e., the full source code of the
file exactly as it existed when the patch was created) is easily accessible.
The theory is that to correctly port a patch from Distro A to Distro B, one
must analyze the full semantic context of the original code to understand the
patch's intent.
The Question: While backporting a commit directly from a package's official
upstream git repository is straightforward, I am specifically interested in
"third-party patches"—those acquired from:
Other distributions (e.g., porting a fix from Debian/Arch/OpenEuler to Fedora).
Mailing list attachments.
Standalone security advisories (CVEs) where only a .diff or .patch file is
provided.
In these scenarios:
Availability: Is it realistic for you to hunt down the exact source tree/commit
where that third-party patch was originally created? Do you typically possess
the full "original source file" (pre-patch state) to see the complete context?
Importance: When you encounter a conflict or a semantic mismatch during
backporting, do you actually rely on finding that original source context? Or
do you mostly rely on reading the .patch content itself and your current target
codebase to resolve it manually?
The Reality: Does the lack of "original context" (e.g., due to squashed commits
in other distros, or lack of metadata) make these patches significantly harder
to maintain, or is this generally a non-issue for experienced packagers?
I suspect that in many real-world cases, maintainers effectively work with
"isolated patches" without access to the full original upstream context.
Any insights—whether it’s a detailed "war story," a brief explanation of your
workflow, or even a simple "yes/no"—would be incredibly valuable to me. I am
eager to learn from your practical experience and hope to spark a constructive
discussion on how we can better bridge the gap between academic theory and
packaging reality.
Thank you very much for your time and for your hard work on Fedora.
Best regards,
Penny
Student
--
_______________________________________________
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
