Re: [FFmpeg-devel] Forgejo entry threshold

From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Forgejo entry threshold
Date: Sat, 9 Aug 2025 20:39:47 +0200
Message-ID: <aJeV87cIaLx9fger@phare.normalesup.org> (raw)
In-Reply-To: <29D4DB17-876E-4077-922D-3F4B4771A2E0@remlab.net>

Rémi Denis-Courmont (HE12025-08-08):
> If your mail client treats attachments the same as inline text, your
> mail client is very badly broken as a mail client. And if not, then it
> is obviously much more cumbersome to review an attachment.

My mail client does not treat text attachments exactly the same way as
inline text, but it makes it extremely easy to view them and quote them
in the reply. It also makes it quite easy to fix the type of attachments
that were mistakenly flagged as octet/stream.

If your mail client does not let you do that easily… well, it proves my
point: a good mail client makes all the difference in productivity and
comfort to interact with the project.

> Also replying to multiple patches in a single mail makes everyone
> else's life miserable for tracking the review.

Then we delete all but the first patch and reply to it, the all but the
second patch and reply to it, and… And we ask the person who submitted
to next time have the courtesy to send the patches in separate mail.

By the way, we could also set up our SMTP server to accept authenticated
SMTP on port 465 with login/password guest/ffmpeg_is_great only for mail
to ffmpeg: it would fix most of the hypothetical “submitter cannot find
a SMTP server” issues.

> But more importantly, email has all the fundamental problems that I
> already raised several times in previous threads.

Sure, but we are in the process of establishing that these “fundamental”
problems are only the consequence of using mediocre mail clients.

> It simply can't compete with something that's designed for code review
> and actually tracks and organises relevant metadata.

What a naïve thing to say. There are plenty of cases where a master
craftsperson is more proficient using mainly one excellent universal
tool than with many specialized tools, even when such specialized tools
might be better for the dilettante. Cooking for example.

> Unless you're using an extremely old or underpowered system that can't
> run a reasonably recent web browser, no.

It only takes a few years of age and/or a cheap computer to make web
apps painfully slow. Not everybody lives in the First World, you seem to
be forgetting it.

I must say, I like my elitism about skills much better than your elitism
about material possessions.

Also, even with an extremely overpowered system, web applications are
still much worse in terms of productivity, because they have to work in
a browser, where ergonomics is very random.

Just consider the editor. Reviewing a patch involves writing text and
code snippets, which is best done with our respective favorite powerful
text editor. But in a web app, unless we engage in clumsy and annoying
copy-paste operations, we have to use the editor provided by the
browser, no choice at all.

Of course, if your mail client does not let you use your favorite
powerful text editor to reply to mail, then it is once again the proof
that the issue is using a mediocre mail client.

So, unless you come up with a trick to invoke Vim from the web monster
with minimal manipulations, you have to admit that switching to it would
make at least a few of us significantly less proficient.

> And if you do, then good luck compiling FFmpeg with it.

It is possible to compiler FFmpeg even on very underpowered computers,
it is one of the main qualities of the project. It will take a lot of
time, but that is not an obstacle since nobody has to stay and watch.
Rebuilding after a small change will take a little time too, during
which the contributor can read a doc or a blog article or do whatever.

Whereas the slowness of the web monsters happens when we are trying to
use them and make using them very uncomfortable, so that is a very
dishonest argument.

> Yeah, we gave. And that definitely doesn't cover sending and reviewing
> patches because that's not what email was intended for. Git didn't
> even exist then.

Any skill need to be updated.

-- 
  Nicolas George
_______________________________________________
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".