[FFmpeg-devel] Project orientation

Soft Works softworkz at hotmail.com
Mon Jul 6 03:58:06 EEST 2020



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Andriy Gelman
> Sent: Monday, July 6, 2020 2:31 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> On Sun, 05. Jul 23:42, Soft Works wrote:
> >
> >
> > > -----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.
> 
> This is done already... and checked for every single commit in the series.
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200701164348.41647
> -1-hanishkvc at gmail.com/


But still the "Michael-Machine" needed to respond manually:

> This breaks build on non x86
> 
> src/libavfilter/vf_fbdetile.c:81:10: fatal error: x86intrin.h: No such file or directory
>  #include <x86intrin.h>
>           ^~~~~~~~~~~~~
> 
> [...]

And everybody in the mailinglist had to read/read this patch even though it
had an error.


softworkz




More information about the ffmpeg-devel mailing list