Re: [FFmpeg-devel] GitHub Integration

[Vasily <just.one.man@yandex.ru>]

Typo correction: "the bot should remove", not "the boy" (oh my mobile
tapping...)

сб, 25 дек. 2021 г., 12:31 Vasily <just.one.man@yandex.ru>:

> 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@hotmail.com>:
>
>>
>>
>> > -----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-request@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-request@ffmpeg.org with subject "unsubscribe".