> -----Original Message----- > From: Soft Works > Sent: Thursday, December 23, 2021 12:25 AM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: GitHub Integration > > Hi, > > holidays are approaching and I got a little present for all of you > even though it won’t be something for everybody. > > A while ago I had committed to prepare a test setup for integrating > GitHub in a similar way as the Git developers are doing. > > For those who missed it or don’t remember the outcome: > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html
I think I should add a quick summary on this subject for all those who haven't followed the discussion in August. The Git project (https://git-scm.com/) has a similar problem like ffmpeg: There are a number of long-time core developers that are strictly rejecting to move away from the ML based approach. That's how GitGitGadget came to life, intending to bridge that gap. Adopting that approach for ffmpeg has a number of advantages: - we can skip the "learning process", i.e. finding out what works in practical use and what doesn't - what has found acceptance at their project - given the similar profile of the developers involved - will likely be acceptable for ffmpeg as well (roughly at least) - the part that I like most is: even without explicit acceptance - this approach doesn't leave much room for objection, because it doesn't impose any changes or drawback to the way people are working with the ML Here's a rough overview about how it's working: - User submits a PR to the GitHub repo - When it's a user's first PR, the ffmpeg-codebot will respond with a very comprehensive message (as PR comment), explaining the procedures and providing an overview about contributing to ffmpeg with links to the individual topics on the ffmpeg website regarding contributing. - The message further explains that first-time users are not allowed to submit immediately, and that a user needs to find and contact another developer who is allowed to make submissions and ask that developer to vouch for him. - Every developer who has been allowed to submit can vouch for a first-time submitter It is done by adding a comment containing "/allow" to the first-time user's PR - Upon submitting the PR (no matter whether first-time or existing submitter), the code bot will likely have posted some other comments, indicating which changes need to be made to the patchset before it can be submitted. - The user addresses those changes and then force-pushes the branch to GitHub, the code bot re-runs all checks and when all requirements are met (and only then), the user will be able to submit. This is done by posting a comment to the PR containing "/submit" The code bot will automatically create the patch e-mails and send them to the ML. (it's also possible to post "/preview" to get the same e-mails created but only sent to a user's own e-mail account) - Comments that are made on the ML are mirrored back to the GitHub PR as comments. The other way is not yet implemented, so at this point, a user will need to respond through the ML (that's clearly indicated). I hope this will be implemented soon, it's not easy though to do it in a nice way without repeating all those quoted lines each time What's really like is the way how you submit new versions of a patchset: - After having applied the changes locally, you just (force-) push the branch again, and post another comment with "/submit" Everything is done automatically then: the patchset version number is increased, new patches are generated and sent to the ML Kind regards, softworkz _______________________________________________ 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".