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

[Zhao Zhili]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Ondřej Fiala
> Sent: 2024年5月2日 22:25
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> 
> 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.

I have tested a few email providers trying to find one which works with git
send-email. Some email providers blocked my emails because they don't know
git send-email and treat patches in email as spam.

And there are email client issues. Michael's email is blank in a very popular email
client. I reported the bug to the developer of that email client, they don't understand
the use case and have no interest to fix it.

I know a developer which have contributed to FFmpeg and stop doing so after
losing his git-send-email environment.

> 
> > >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.)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".