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-requ...@ffmpeg.org with subject "unsubscribe".
