[FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> ffmpegandmahanstreamer at e.email
> Sent: Wednesday, 11 August 2021 15:01
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
> 
> August 10, 2021 10:37 AM, "Soft Works" <softworkz at hotmail.com> wrote:
> 

[..]

> > Just recently, I discovered a very interesting project:
> > https://gitgitgadget.github.io
> >
> > This is all about the development of Git itself, which is done via
> > mailing list and they had the same problem, namely developers that
> > could never be convinced of using GitHub instead of the mailing
> > list. That’s how GitGitGadget came to life:
> > https://github.com/gitgitgadget/gitgitgadget/blob/main/DESIGN.md
> >
> > Now my suggestion – obviously – is: Adapt the GitGitGadget
> > implementation and employ it for ffmpeg development.
> 
> This is a wonderful idea, if it works side in side by the mailing
> list. I have actually been thinking about this at the back of my
> head.

[..]

> However, with this idea, will people still submit more patches? One
> of the benefits about github is that you don't need to create a new
> account and do all that extra stuff.

On GitHub you _do_ need to create an account to submit pull requests
(which are like patchsets and can contain multiple commits/patches).

> If someone was going to sign up
> for gitgitgaget already and is going the extra mile, they are the
> same ones most likely to be willing to sumbit to the mailing list as
> well.

It doesn't work like that. In fact giggitgadget just works in the 
background invisibly. The procedure is:

- [optional] a GitHub user might need to get accredited to be 
  allowed to submit PRs(to reduce unnecessary noise)
  In case of GIT, it is sufficient when a new developer gets
  approved by any other already participating developer

- A developer submits a PR at github.com/ffmpeg/ffmpeg

- The automation performs some automatic validation checks whether
  the submission is acceptable

- The developer adds a comment containing "/submit"

- The ggg automation automatically sends the PR as patchset
  to the mailing list

- Comments in the mailing list are mapped back to the GitHub PR

- When a developer make changes to PR and "/submit"s again,
  a vN patchset is sent to the mailing list


What also works is the other direction: patchsets that are submitted
to the mailing list are automatically mirrored as PR in the 
GitHub repo.

As said, the really good thing is: nobody would need to change
the way he is working.

softworkz