[FFmpeg-devel] Project orientation

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Jean-Baptiste Kempf
> Sent: Sunday, July 5, 2020 11:48 PM
> To: ffmpeg-devel <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> On Sun, Jul 5, 2020, at 22:50, Michael Niedermayer wrote:
> > > Having your
> > > patch being not responded to (whether being forgotten, not found
> > > interesting enough, or whatever other reason) was.
> >
> > At least for me the reason to not review a patch is often simply time.
> > But i agree the amount of not reviewed patches is a problem.
> 
> Yes.
> 
> > How can we solve this ?
> 
> With tools and organization.
> 
> Today, any patchset that has several patches (like the 36 ones for VP9 of the
> other day) or multiple revisions gets everyone a ton of emails. When you are
> at the revision 3 or 7, you completely lost track, unless you know exactly
> what to look for. Seeing the difference from the 2 revisions is very hard. So
> either you spend a lot of time understanding and re-reading or you drop it.
> So, either inefficiency for the reviewer, and therefore less reviews, or
> forgotten patches.
> 
> Today the patchwork has 64 pages of patches...
> 
> Noone human can know all that is happening.
> 
> So either you split the mailing list and patches per library (different for
> libavcodec, format), with submaintainers for each library, basically, like the
> Linux Kernel does.
> Or you move to github/gitlab which gives you by default a tracking of the MR
> that got merged or not, where you can see quickly the differences between
> 2 revisions of a patchset and where you can use tags to mark the merge
> requests, where the CI is automatic, so you don't have to check manually
> that the code compiles or that FATE is not broken, etc...

+1 for this. 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.
Neither should it be required that Michael responds manually each time 
by stating "breaks FATE".
Also, this would allow review comments stay connected to the commented
code parts forever. When in the future somebody wonders why something
has been done in a certain way, it will be easy to find that discussion.

softworkz