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

["Ondřej Fiala" <ofiala@airmail.cc>]

On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote:
> 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:
> > > 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.
This argument can actually go in both directions since the Web and web
browsers weren't meant for performing code review either. If you remember,
the Web was originally intended for sharing *documents*, which a MR page
on GitLab definitely isn't.

IMHO, the fact that something was intended for some use case does not imply
that it's actually good for that use case. My point was that what it was
meant for does not matter, what's important is if and how well it works
for that use case.

> > 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.
I said *depth*, not *length*. AFAIK GitLab can't create message threads like:

  message
  |- reply
  |  |- reply 
  |  |  '- reply
  |  '- reply
  '- reply
     '- reply

> > 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?
Why would you do that in a mail client? You have your personal copy of the
repo, so you can just import the patch by piping it to `git am` and then
use any of the wide array of git-supporting *specialized code review software*
to look at the changes!

Of course, the quality of your toolings matters a lot. If your email client
can't pipe a bunch of emails to a shell command, it's not fit for being used
to review git patches. On the other hand, if you possess just some basic shell
scripting skills, you can make it do pretty cool things.

Since you felt that there is no way to see additional context, I put together
a quick demo[1] showing how easily you can review all files affected by a patch
and look at *all* the context. Of course, you could do a bunch of other things to
adjust the email-based workflow as desired. And don't forget this is just a demo;
I am sure you could come up with something better.

[1] https://paste.c-net.org/HansenWeekends

It's just sway, aerc, and a fuzzy picker combined. The command "changes" is just:
  changes() {
      while p="$(git diff --name-only origin/master | pick)"; do
          git diff -U9999999 origin/master "$p"
      done
  }

> > > 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.
I must admit I did not realize how bad some email/internet providers can be
when writing this, as I have a fairly average setup and never ran into such
issues.

But the problem with accessibility is not aleviated by switching away from
email, since those forges aren't universally accessible either. I remember how
I used to run Pale Moon like 2 years ago. In case you don't know, it's a Firefox
fork maintained by a small team. GitHub didn't run on it. Oh, sorry, you don't
care about GitHub. But they share the same desig -- hugely complex "web app"
that only runs on latest version of major browsers. Everyone else is excluded.
When I wanted to contribute to a project I really cared about, I had to download
mainline Firefox and do it over that. If I cared even a bit less about it, I
wouldn't bother.

So how is that any different?

I think the solution to the email issues you mentioned could be to have the
ability to upload patches through the SourceHut UI directly. Since SourceHut
is still not feature-finished AFAIK, it could actually be added if there was
enough interest.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".