On Wed, Jan 14, 2026 at 3:18 AM Jian Peng <[email protected]> wrote: > > 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. >
Hello Penny, I am a little unusual among package maintainers in Fedora as I have participated in multiple distributions, but let me see if I can answer your questions. :) > 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? > As a general rule, we usually are able to do this. Most Linux distributions maintain a public change control system of some kind that shows how the deltas were created. And we generally can expect some information on why they were created to be available too. There are some exceptions, where sometimes the tracked information is very minimal and linked to a private bug report (for e.g. security issues or in the case of it being an enterprise Linux, a customer issue that can't be extrapolated properly). I've hit this case a couple of times with patches originating from the openSUSE project, and there's a process to request details from SUSE for such issues (which I have used once). > 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? > I rely on all three. I need to know the meaning, the nature, and the objective (which usually comes from that information) and it is entirely possible I will make a brand new patch as a result. I have done this before when the issue being fixed with the patch still remains, but the codebase has changed so much that I need to figure out how to fix it again. > 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? > It can, but it doesn't always. As I mentioned before, it's pretty common to have some kind of change control information, and so patches often have two layers of metadata: the direct metadata associated with the patch, and the metadata from the change control system as the patch itself was introduced and refreshed. I have used that information to make much better decisions of what to do with patches. But it is also possible to encounter cases where you don't have that. In that case, the larger the patch, the harder it is to figure out what's going on. And if this is combined with a highly iterative series of patches, it's even more complicated because there are two dimensions to track to understand the full context. So I'd prefer a squashed patch over an iterative patch set. > I suspect that in many real-world cases, maintainers effectively work with > "isolated patches" without access to the full original upstream context. > This used to be very common, especially back when the Enterprise Linux distributions didn't have public change control. RHEL and SLE both have this in the form of CentOS Stream and openSUSE Leap, respectively. But now I really only experience this when I'm looking at patches from more unlikely sources of distribution patches (e.g. PCLinuxOS) that don't have public source control (which is very rare now). > 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. > I'm a little bit of a weirdo among Fedora packagers in that I also contribute to other Linux distributions, and I've also been around long enough to have seen Fedora change the way it maintains its packaging repositories multiple times. As a consequence, I have a decent skill in finding out how other distributions maintain their sources and have taken advantage of that to have a better understanding of their decision-making. It is not uncommon to find patches from me in virtually every reasonably popular distribution because of this, as well as several that are fairly unknown to most people. I always feel strange when I encounter this, because it's still weird to me that my stuff is so useful that everyone copies it. :) One aspect of the reality is that the Linux distribution world is a smaller space than people realize and due to the nature of it, we do eventually meet in some shared space. Usually this is in some open source project communication space (a bug tracker, a chatroom, etc.), but sometimes it's unconventional (like a meetup or seminar/webinar). > Thank you very much for your time and for your hard work on Fedora. > I don't know if you're a Fedora user, but if you are, welcome to the community. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
