> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Jean-Baptiste Kempf > Sent: Sunday, July 5, 2020 11:48 PM > To: ffmpeg-devel <ffmpeg-devel@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
