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

[epirat07 at gmail.com]

On 2 May 2024, at 21:32, Ondřej Fiala wrote:

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

How do I see the review comments that way?

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

So I first have to get proficient in some shell scripting gymnastics
(and also switch to a completely different terminal-based mail client)
so I can do proper reviews?

Thats incredibly gatekeeping.

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

That seems to download some binary file? I have no idea what it is supposed to be.

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

How is it different to download a well maintained recent software and open a website,
in comparison to learn how to setup a (complex) combination of tools just to be able
to easily contribute?

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