[FFmpeg-devel] [RFC] 5 year plan & Inovation

Ondřej Fiala ofiala at airmail.cc
Thu May 2 17:25:06 EEST 2024


On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
> Le 30 avril 2024 22:15:10 GMT+03:00, "Ondřej Fiala" <ofiala at airmail.cc> a écrit :
> >On Tue Apr 30, 2024 at 9:06 PM CEST, Hendrik Leppkes wrote:
> >> I will take the replacement instead, thanks. Email is archaic. The
> >> entire point is to get away from email, not dress it up.
> >> SourceHut usage would likely make me even less interested then today.
> >>
> >> - Hendrik
> >I guess that depends on how (and with what) you use it. Using it with
> >Gmail UI for example is obviously not a great idea. No idea whether you
> >do, but if you do, you should be upset at Gmail, not email.
>
> I don't use Gmail, and using email for review still sucks. No matter how you
> slice it, email was not meant for threaded code reviews.
Email was not meant for a lot of what it's used for today. Many email clients
have support for threading, and unlike GitHub allow threads of arbitrary
depth. Using such a client with commands for moving between messages in a
a thread etc. makes threaded code review over email quite usably in my opinion.

> Also while I can use git-send-email, not everyone can. And patches as
> attachments are simply awful. Unfortunately I can't dictate that people don't
> send patches that way.
How can anyone use git, but not git send-email? Any decent email provider
has support for external clients over SMTP. And I believe you *can* actually
dictate that people don't attach patches -- if you have control over the
mailing list software, you can set up a filter that rejects such emails
and auto-replies with instructions on how to send them properly.

> >But you did not answer my question: which specific code review features
> >are you missing?
>
> Proper threaded reviews with state tracking, ability to collapse and expand
> context and files, and proper listing of open MR (*not* like patchwork).
I can sort of understand everything except the last one. What is "a proper
listing of open MR" supposed to mean...? (I know what a merge request is,
of course, but I don't get how the way GitLab lists them is supposedly
superior to SourceHut's list of patches.)


More information about the ffmpeg-devel mailing list