Hello everybody,
this is a follow-up to the recent discussion on IRC (https://libera.catirclogs.org/ffmpeg-devel/2025-05-16) about patch submission via https://github.com/ffstaging/FFmpeg. It involved such preposterous statements like: "you've been refusing to use proper submission procedures, tried to introduce your own" and raised some other questions that I would like to address: What is it? =========== The implementation is adapted from GitGitGadget (https://gitgitgadget.github.io) for FFmpeg without functional changes. GitGitGadget is developed by Git developers. Git development goes through a mailing list, same like FFmpeg. Instead of using git send-email directly, developers can send patches via GGG on GitHub which is also advertised in their documentation (https://git-scm.com/docs/SubmittingPatches https://git-scm.com/docs/MyFirstContribution). So, for anybody who's trying to depict the ffstaging submissions as something different or bad, we can tell for sure: - If there would be anything wrong about it, then the Git developers themselves would be the very first people in the world to know about it - The way how it works is how the Git developers consider it to be correct Long E-Mail Threads =================== GGG runs format-patch with --thread=shallow (and sends the e-mails itself), that gives the same result as when using git send-email (where the default it --thread=shallow). In turn, each patch e-mail will show as a reply to the cover-letter (0/X). But additionally, it specifies the --in-reply-to parameter - pointing to the cover letter of one the previous revision. This chaining is essentially what is causing the threads to become huge. It ties all revisions together. When looking at the Git docs for developers (https://git-scm.com/docs/MyFirstContribution#v2-git-send-email), we can see that this is intentional: According to the docs for manual submissions, it's a requirement to do this when sending new revisions of a patchset. As that is not a requirement for FFmpeg, I have removed this behavior now! ============================= Other comments were: "kludgy github submission on your end where you dump huge patches" "it highly encourages huge patchsets" Does it cause large Patchsets? ============================== It is not quite clear how one might come to think that. Maybe the idea is that it would require to always push new additional commits to GitHub and that this would make the patchset longer with each revision? => Of course not. The reason why the patchset grew from 10 to 15 was from review comments like "this should be in a separate commit" - so I separated them. The last commit of the patchset has always been the last one, since v1. Or is the idea perhaps that it would make it easier to deal with larger patchsets? => First of all, that would be great and nothing bad - but no! When using git send-email, you are running a single command. What's tedious is to write that command, but it doesn't matter whether it's 3 or 30 commits. Same for the GitHub path, you just don't need write the command. Finally: The way I'm working doesn't depend on the submission procedure. Even when I had to print out everything on paper and send it by postal mail, that wouldn't make any change. No idea how someone could think it would be any different. And for this comment: "Even if it posted it as a new thread each iteration, the general problem is that it causes too many full iterations still remains" => I'm not sure how it could "cause too many full iterations".. If it's about "many": The number of iterations I send is not dependent on which tooling I use. Just because I find submissions via CLI tedious doesn't mean that I would do it differently. If it's about "full": I've never sent new versions of individual patches only from a set and I'm not intending to do that. Here's why: I rarely have patchsets which are just a collection of independent patches. But when it would turn out that there one patch in such a set that needs more discussion or review, then I rather remove that one from the set and resubmit that one separately. In all other cases, where patches are depending on each other, I'm expecting for each revision I send, that it will be the final one (except the first few in a complex set). If I wouldn't think that, I normally wouldn't send it (or mark as RFC). The final revision should be all-green on Patchwork and you can't get that with just partial patches sent. That's why I don't see much point in this and I also see it done by others just very rarely. Yet I'll try to send less revisions in the future. Thanks sw _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
