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

Rémi Denis-Courmont remi at remlab.net
Thu May 2 17:38:00 EEST 2024


Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit :
> 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.

And Gitlab and Github are meant for what they are used.
That's the whole point.

Maybe (probably) email is better than any other tool that was not meant for 
code review, but not than a dedicated tool. But to claim that email is better 
for code review that dedicated tools is very highly disingenuous. People 
wouldn't have spent so much effort developping those tools, and they would not 
be so popular.

> Many email clients have support for threading,

No, they don't. Email threading is *not* the same as code review threading. 
And then email clients also can't track open/closed states.

> and unlike GitHub allow threads of arbitrary depth.

I don't care because *GitHub* is out of the race for other reasons anyway. I 
have never had a situation whence *Gitlab* refused to add more comments to a 
thread.

> 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.

So how do I ask my mail agent to pull more existing code for context? Or to 
get back to the code that started a thread?

> > 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.

Simply put: no, that is simply not true.

Not everybody can pick a decent email provider with outbound SMTP and a good 
reputation. Also not everybody gets to pick their mail agent or their ISP.

You are just being unwittingly elistist here.

> 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.

Yes but then those people can't contribute at all.

-- 
Rémi Denis-Courmont
http://www.remlab.net/





More information about the ffmpeg-devel mailing list