[FFmpeg-devel] GitHub Integration

[Soft Works]

> -----Original Message-----
> From: Soft Works
> Sent: Thursday, December 23, 2021 12:25 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel at 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