Hi. I am not on IRC either, so I can not comment on what happen there. I hope I have not shown myself what you consider hostility on this list. I will try to explain what I think may irritate people in your actions on this list.
I will not comment on the issue of pushing without having addressed comments and similar issues, they are basically misunderstandings that time will fix. In short: you should have already moved to the next level. In less short: you have found a few easy ways of enhancing the code (consistency in variable naming, enabling warnings and fixing them), and made good of them. Very well. There is nothing wrong with starting easy, almost everybody did. But now, you continue digging in the same veins, although they are mostly dry. For example, the integer stuff: yes, theoretically it violates the C standard, but most of it will never be an issue, because the extra assumptions it makes (32-bits integer, two's complement for sign) will be kept for ever. Remember that FFmpeg's code is significantly above standard when it comes to portability: if FFmpeg breaks, a lot more program break too, and that would not be acceptable for the people who design compilers. After your first contributions, people will expect that you would have become capable of evaluating the value of these bugfixes. Remember that even a small and obviously correct fix has drawbacks: it may cause merge conflicts, and therefore more work for Hendrik, it pollutes the output of git blame and may take one more git bissect step. And simply it may make the code slightly less readable. For example, the log10 stuff: yes, the change is valid, but in most places, it does not matter at all, the extra accuracy and speed are irrelevant. So do not waste your time, and the time of the people you ask to review your patches, on this. If you find a place where the difference is critical, then of course go ahead, well done; if you see new code that should use log10, comment before it is applied; all this is worthy. But for most of the existing code, leave it be, because the enhancement is too small compared to the drawbacks. And for yourself: how much thinking efforts did you need to produce the log10 patches? My guess is: almost none at all, you noticed the possible change and the rest was completely straightforward. Does it satisfy you? Instead, start spending your efforts on more difficult tasks. That is what I meant by "next level". Unless I am misremembering, all your changes only had a local influence: the syntax of an integer constant, a formula or a function call, at most, a whole mathematical function. But you have the skill to try to understand how the function interact with each other, to address issues that require understanding how a whole subsystem works. If you need ideas on what to try, look at the trac ticket, especially the ones that are "reproduced by developer" (so you know it is not just a PEBKAC) but not "analyzed by developer". But if dealing with people's bugs annoy you, there are plenty of tasks where your skills could be useful: just find some aspect of FFmpeg's behaviour that you find annoying and try to find a way of enhancing it. Error messages drowned under information messages, more readable output for the stream summaries, etc. And of course, there are many ideas floating around: non-blocking demuxers (hard), more FATE coverage, simplifying codex context cleanup, DATA media type in lavfi (hard), merging the libraries in a single one. And of course, you can come up with your own ideas completely out of the box: a GUI to explore codec options? make an API to access the documentation? a web interface to manage patches? So to summary my advice: try to attack harder problems, you are ready for it and that would make your contributions even more valuable and well received. HTH Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
