[FFmpeg-devel] GitHub Integration

Vasily just.one.man at yandex.ru
Sat Dec 25 11:31:56 EET 2021


Hi,

First off, a great idea bridging that gap! But I agree that the topic is
misleading, maybe rename to smth like "github bridge for PR creation" to be
really explicit?

Second one, why first-comers aren't allowed to submit without pre-approval?
(context: I haven't made my contributions to ffmpeg yet, though posted a
single patch which stalled at review because of lack of my time).

And last point - if comments from github aren't re-posted to the list,
maybe the boy should remove them or edit by removing the message and
telling the commenter to use the ML?

Anyway, good idea!

Thanks, Vasily


пт, 24 дек. 2021 г., 1:30 Soft Works <softworkz at hotmail.com>:

>
>
> > -----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
>
>
>
>
>
>
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>


More information about the ffmpeg-devel mailing list