The way the specfile pulls in the latest git commit as a patch against the release tarball is new to me. I interpretated that workflow to mean those before me thought it was important to document all the commits that were made. That's why I did not add the patch as a rfpkg source and instead included it with our git history. However, if I do add the patch file as a rfpkg source per the original request, then why bother pulling down the changes as a separate patch at all? Rpmfusion github won't track the changes this way. Why not keep it simple and pull in one tarball that contains everything? Just looking to understand. Le dim. 28 févr. 2021 à 08:08, Gary Buhrmaster <gary.buhrmaster(a)gmail.com&gt; a écrit : I think it will be even more relevant to compress (gz, xz, etc) the patches from upstream Then you can just apply them compressed, the %patch macro will deal with the compression while applying. The reason why I think this is revelant for lookaside is that the patches where already applied/reviewed upstream, So having "peer reviewing", on the rpmfusion mailing list, for any eventual other downstream patch will be hidden or much more difficult. _______________________________________________ rpmfusion-developers mailing list -- rpmfusion-developers(a)lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-leave(a)lists.rpmfusion.org