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... -- Jean-Baptiste Kempf - President +33 672 704 734 _______________________________________________ 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".
