[FFmpeg-devel] Project orientation

[Manolis Stamatogiannakis]

On Sun, 5 Jul 2020 at 19:01, Kieran Kunhya <kieran618 at googlemail.com> wrote:

>
> For new contributors git send-email is annoying. For people wanting to
> push, the .mbox format is annoying, Gmail doesn't support it any more.
> And you can't get new contributors to start using CLI based email
> clients or run their own mail server, that's not going to happen.
>

As a fresh contributor, setting up git send-email was a hassle, but
not an insurmountable obstacle.

Though I'd argue that git send-email is a bigger liability for regular
developers. A lot of developers seem to be using Gmail, which means they
need to have  "less secure apps" enabled at the time they use git
send-email. So they are forced to choose between security and convenience.
I.e. having to temporarily enable  "less secure apps" every time they
submit, or accept the risk of weakened security for their account.



>
> A solution like Gitlab is the only way forward. It has worked well for
> dav1d, it can run regression tests on all platforms for all commits:
> https://code.videolan.org/videolan/dav1d
>
> Merges are done with one push of a button. Yes, the branch sprawl is
> not great but it's better than now.
> It has inline patch reviews which are nice.
>

FWIW, I'd add that branch-based PRs as implemented with GitHub greatly
reduce the turnaround for receiving feedback and addressing the raised
issues.
All you have to do is force-push on your PR branch, and the PR is cleanly
updated.
This is in contrast with having to use git send-email, where the emails
containing the stale patches will continue to litter patchwork and your
mailboxes.

Also, IIRC, when you update a branch, the regression tests for all pending
PRs on the branch are automatically rerun.
This should help address the conflicts in the pending PRs sooner rather
than later.

Not sure what the status of GitLab is wrt to these features, but I'd expect
it to not be very far behind.

Best regards,
Manolis