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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
