[FFmpeg-devel] possible farewell; dev policy clarification

Nicolas George george at nsup.org
Fri Oct 30 15:07:00 CET 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151030/80548519/attachment.sig>


More information about the ffmpeg-devel mailing list