Hi, Penny. > Availability: Is it realistic for you to hunt down the exact source > tree/commit where that third-party patch was originally created? For patches from other distributions, the package metadata will typically define where the "base source" that patches are applied to come from. As such, it's often enough just to compare the URLs - though arguably, one should also verify if the actual source matches what the metadata claims.
For patches from mailing lists, the few times I've had to rely on those, the message containing the patch was part of a discussion about a specific version of the software failing to build. In which case, yes, there may be some "hunting down" involved, though that's often not necessary (see below). > 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? This very much depends on a case-to-case basis. Simple scenarios like missing identifiers or mismatched types can be solved using just the patch and the current target codebase. For more complex scenarios, having the original source helps, but not as much as having full version control history and being able to trace intermediate changes. Being able to follow the code's changes makes it way easier to determine what is relevant, and what can be removed. Also, as much I'd like to claim that I properly review every single patch that ever appears in front of my eyes, the fact is that software is written in many different languages, using different libraries, and it's impossible to know them all. So sometimes, if I work with an unfamiliar technology and a third-party patch fixes my issue, a cursory "does this look sensible, or like a terrible hack?" rating is pretty much the only scrutiny it gets. > 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? This may make patches harder to introduce, as you need to solve any conflicts that may be caused by the differences between the "patch source" and your target source. But once that's taken care of, I'd say maintaining an edited third-party patch and one that I've authored myself take about the same amount of work. Most software doesn't have new releases all that often, which means that typically, by the time a new version comes out and the patches need updating, I have forgotten most of the context anyway, so - once again - there's not much difference between updating a third-party patch and an original one. > 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? I wouldn't consider it a deal breaker, but it would definitely limit the applicability of the tool. While I appreciate a tool informing me that I might have made a mistake, or that the input data is incomplete and it might produce unsatisfactory results - I think that having a "yes, I know what I'm doing" override would be very much preferable. Also, like I wrote before, personally I find version control history provides even more and even better context info than just having the original source. It'd be great if this potential tool could utilise this. Cheers, AFI -- _______________________________________________ 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
