August 11, 2021 9:44 AM, "Soft Works" <softwo...@hotmail.com> wrote:
>> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of >> ffmpegandmahanstreamer@e.email >> Sent: Wednesday, 11 August 2021 15:01 >> To: FFmpeg development discussions and patches <ffmpeg- >> de...@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration >> with GitHub >> >> August 10, 2021 10:37 AM, "Soft Works" <softwo...@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). But the changes of someone having a github account is higher than gitea, so to speak. > >> 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. > Oh, ok i understand now. This is a genius idea. I think it's a gamechanger. Thanks for bringing it to our attention. > As said, the really good thing is: nobody would need to change > the way he is working. > > 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". _______________________________________________ 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".
