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

[Michael Niedermayer]

On Fri, Aug 13, 2021 at 11:53:54PM +0000, Soft Works wrote:
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Michael Niedermayer
> > Sent: Friday, 13 August 2021 20:10
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> > with GitHub
> > 
> > On Fri, Aug 13, 2021 at 03:14:36PM +0000, Soft Works wrote:
> > [...]
> > > > You do not need anybody's permission either to set up a gateway
> > that
> > > > will re-post GitHub's PR and comments to the mailing-list and
> > > > reciprocally
> > >
> > > I would need permission to github/ffmpeg/ffmpeg in order to set
> > > up the automation hooks.
> > 
> > what exactly is needed to be done, what exact permission is needed
> > are we talking about adding a link  /API key somewhere or
> > continues maintaince of some parameters which require specific
> > permissions?
> 
> This is implemented via typescript functions running on Azure, 
> so it will be rather a one time setup, at the side of the GitHub
> repository and maintenance can be done at the Azure site.
> 
> BTW, do you own https://dev.azure.com/ffmpeg or has somebody else
> registered that one?

I dont know who created dev.azure.com/ffmpeg nor do i know how/who to ask
i just get a "401 - Uh-oh, you do not have access." on that page


> 
> I could register something like ffmpeg_sync or ffmpeg_ggg otherwise
> and transfer ownership to the project later (or upfront).
> 
> > > Also I wouldn't do it as long as there is at least some kind
> > > of "let's try it out as an experiment" feedback from here.
> > 
> > I think ultimately none of us knows how it would look/behave before
> > its done. So its hard to avoid that it would be an experiment
> 
> Surely true.
> 
> But even when it wouldn’t work well in terms of submitting - the
> other direction alone would be a great value IMO: being able to 
> view patches submitted to the ML mirrored as GitHub PRs.
> This allows viewing patches in context of the latest master-HEAD
> without needing to fetch latest, download patch and apply patch
> locally.
> 
> 
> > I do not know "GGG", but what happens once a PR is submitted to the
> > ML?
> > People will write replies on the ML to comment, ask for changes and
> > so forth.
> > Simlarly on github PRs can receive comments, reviews, approvals and
> > so on
> > is there some routing of such comments between PR and ML ?
> 
> Yes there is, but currently only from mailing list back as a PR comment
> PR comments are not yet sent to the ML. Need to find out the reason
> why the aren't doing it or add this functionality. 
> Essentially, developers are still required to reply on the mailing list.
> 
> But what's nice is that developers can make the requested changes
> to their PR source branch, /submit again and GGG will automatically
> submit this as v2..vN patchset.
> 
> I think it's best to look an example: 
> 
> https://github.com/gitgitgadget/git/pull/1006 
> 

> > another thing needed, if we would allow PRs is that automated fate
> > testing
> > of such PRs should be implemented. Thats a great way to filter out
> > bad PRs beyond just a author list
> 
> Yes absolutely. This can be done just normally as GitHub checks/actions:
> 
> - Conformance of submit message
> - Compilation (ideally multiple platforms)
> - FATE
> - Possibly some code style checking
> (for GIT, they have set up 46 checks currently)
> 
> They don't make successful completion of all checks a requirement, 
> but that's something I would possibly change.

Yes, i think it would be nice if basic formating of commit message, builf&fate
is required to pass before submission. This simply cuts down on message volume
as noone has to manually send a mail asking for these changes.


> 
> 
> What I'm still thinking about is the part about hooking into ML 
> e-mail reception. They are using https://public-inbox.org/
> for GIT, but it would need to be hosted somewhere.
> Either I'll figure out a different way or I'll self-host it for an
> initial phase.

I think you should talk with Andriy Gelman, he is maintaining the VM with patchwork

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210814/2920524a/attachment.sig>