[FFmpeg-devel] Project orientation

[Nicolas George]

Kieran Kunhya (12020-07-05):
> Going back to the original point in hand.

This was not the original point at all, but it does not matter much.

> Many patches aren't getting reviewed and pushed any more.
> 
> In part this is because in 2020 whether we like it or not mailing
> lists are not the way to do Git based development.
> The kernel is the exception to the rule, as Linus says it has a whole
> load of grey-bearded system maintainers who are paid full time to work
> on it.
> 
> For new contributors git send-email is annoying. For people wanting to
> push, the .mbox format is annoying, Gmail doesn't support it any more.
> And you can't get new contributors to start using CLI based email
> clients or run their own mail server, that's not going to happen.

Please, this is oversimplification and caricature. I urge you, for the
sake of sane discussion, learn a little about the arguments of the other
side.

* You don't need to set up a mail server to use git send-email, it is
  perfectly usable with any SMTP server, including GMail's.

* You can use any GUI mail client to work on FFmpeg, including with GMail.

* GMail's warnings about "less secure" applications are scare tactics to
  get you to exclusively use their products, because they cannot feed
  you advertisement when you use a real mail client with their IMAP and
  SMTP servers.

* And you can make bullet lists in plain mails, I just did. I would
  argue that if you do not know how to make a bullet list in a plain
  mail, you would not be able to make a bullet list in a C comment.

> A solution like Gitlab is the only way forward. It has worked well for
> dav1d, it can run regression tests on all platforms for all commits:
> https://code.videolan.org/videolan/dav1d
> 
> Merges are done with one push of a button. Yes, the branch sprawl is
> not great but it's better than now.
> It has inline patch reviews which are nice.
> 
> Whether we like it or not web interfaces are the way 95% of the world
> does Git and we have to move with the times.

I will speak about my case, but I am pretty sure it applies to a few of
my fellow developers, including a few of the very important and core
ones.

I know and know how to use both command-line and graphical tools to
program and develop, and I know this: I am immensely more efficient with
command-line tools.

There are many reasons for that. Command-line tools make together a
programming language, and I am good at programming; GUI tools, when they
allow programming, usually allow it in a clumsy way and only for the
things that were explicitly designed. Command-line tools tend to be much
more predictable in their fine behaviors, GUI tools have windows that
appear in unexpected places and the focus that gets lost somewhere. I am
much more agile with my fingers than with my whole arm, and hitting a
few keys in rapid succession requires less fine motor control than
hitting places on screen in rapid succession.

I do not like being inefficient, I despise it. Therefore, developing
with graphical tools is for me a pain. If I have a strong incentive to
do it, I will do it. But for fun? No, thanks.

I do not begrudge you your choices of tools to program an develop. Quite
the contrary, I want you to be able to use the tools you prefer. Git and
all the software around it are designed for that: they can be used
directly, but they can also be used within interfaces, and still work
with the raw versions.

You can use all the interfaces you need to make your work with FFmpeg as
comfortable as you want. If you find somebody to install and maintain
it, you can have all the interfaces you want available for all potential
developers.

But be very careful to not make them mandatory.

If the infrastructure of the project evolves to let us all use GUI tools
easily, then I will just not use them, or use them only in the rare
cases where they are more convenient than command-line.

But if the infrastructure of the project evolves so that only GUI tools
can be used, if I can no longer communicate with Mutt, program with Vim
and manage things with Zsh and the associated tools...

Then the project is no longer for me, and goodbye.

(And note that goodbye also means: good luck finding somebody who
understands how libavfilter works. I have tried to document as much as I
could, but the task is huge, and nobody but me seems interested anyway.
Goodbye from other core developers would similarly mean significant
parts of the code becoming orphan of know-how.)

A note about web interfaces. My point is that I want to use the software
of my choice. With web interface, the web browser is not the software of
my choice. First, the web browser is not the software, it is the runtime
environment; the software is the set of scripts running in the browser.
Unless there is also a low-level web-API interface, and an usable one,
not one that requires thousands of lines of code from undocumented
libraries just to authenticate, we cannot choose the software.

And web browser themselves are not the software of our choice, they are
the poison of our choice. They are no good Libre Software web browser.
There is an oligopoly that makes the web browser into a tool to
force-feed us consumerism, one Open Source alternative that tries to
match them misfeature for misfeature, and a billion forks that try to
address some of the flaws but since they are based on the same code base
they suffer from the same fundamental deficiencies.

So again, if the infrastructure of the project evolves to require us to
use more web interfaces, then for me it is goodbye.

(Basically, I don't have a beard, I am definitely not getting paid to
work on FFmpeg, but my relation to programming is the same as the "load
of grey-bearded system maintainers who are paid full time to work on"
Linux. And I suspect a significant part of the knowledge about FFmpeg's
code base lies in people like us.)

Therefore, I urge you: think very carefully, when advocating for more
"welcoming" tools, whether it would lose the project irreplaceable
developers.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200707/38490536/attachment.sig>