[FFmpeg-devel] possible farewell; dev policy clarification
gajjanag at mit.edu
Fri Oct 30 16:10:09 CET 2015
On Fri, Oct 30, 2015 at 10:07 AM, Nicolas George <george at nsup.org> wrote:
> 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.
I guess this boiled down to a question of timing: I kept postponing
the plan to move to the "next level". Maybe I took too much comfort in
simple changes, without considering the negative "social aspects". I
personally had set roughly Jan/Feb of next year for such a move. Your
comments and other reactions have convinced me that is best if I do so
Here is the solution I propose. I do not want to leave mini-projects I
began unfinished. However, I understand the negative reactions. I will
limit "cosmetic/simple changes" to one patch per day (at max) to not
flood the ML. This will slowly let me get rid of e.g
av_warn_unused_result baggage, while transitioning to other work. Does
this sound agreeable to all?
> 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?
I would have been ok if it did not result in this much ML noise. But
given the overall episode, I do regret it.
None of these things are satisfying, but to be honest, I am not
looking for satisfaction from FFmpeg.
I am looking for a way to channel frittered away energy obtained
during my transition from undergraduate to graduate life and its
associated increase in flexibility of time allocation.
In other words, I want a way to spend my down-time that is technical
> 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.
Looking back, I think the first commits I made were perhaps among the
best ones I did: they were simple, but fixed tickets in clean ways. I
can take it to the next level by focusing on ones that require
understanding of interactions. Or perhaps the closest example to what
you have in mind is the ffplay volume control, it is something I
personally found annoying (I solely use ffplay for playback, mpv and
vlc are not even installed on my system). On a lighthearted note, the
reason for my setup is because by default, ffplay displays a
spectrogram for audio files which appealed a lot to some of my signal
processing background :). Any mpv/VLC people can take this as an
informal "feature request" - VLC definitely did not do this a year
> 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
> 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.
Great summary. A lot of things have been clarified, and I have only
one question on how to move forward (the proposed rate-limiting of
cosmetic/simple patches from my end that I proposed).
Thanks to all for comments on this.
> Nicolas George
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel