[FFmpeg-devel] Project orientation

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Monday, July 6, 2020 1:18 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> On Sun, Jul 05, 2020 at 09:56:02PM +0000, Soft Works wrote:
> > ... A significant part of code reviews are code-style violations. This
> > is really not something where humans should need to spend time for
> > when reviewing a patch.
> 
> you are correct but that is also the easy part of reviews.
> Its not what makes reviews time consuming.
> Rather while reviewing for technical stuff one notices maybe a formating
> issue

When then reviewer would not have to look for code style and could
assume that this is all right, he would be free to focus on the actual things.
And when it's only about code-style, a reviewer would not need to
review a patch two times (original + corrected) for checking whether 
there were no other changes (imagine a multi-part patch).
Also, the contributor would not have to wait two times for his patch 
to get reviewed.

Continuous integration processing could also list compiler warnings
isolated to the patch and help a reviewer spot issues that he might 
have overlooked otherwise.

> > Neither should it be required that Michael responds manually each time
> > by stating "breaks FATE".
> 
> We already have fully automatic build and fate tests for submitted patches its
> done by patchwork which should send a private mail to the submitter of a
> patch affected.

And still you're sending those e-mails..

> Still not every environment is the same, and it passing on the patchwork box
> doesnt mean it builds on my mingw or mips environments for example.

Such things could be set up easily, either for free or for little money... ;-)

softworkz