[FFmpeg-devel] possible farewell; dev policy clarification

[Rostislav Pehlivanov]

I agree with the others. There's quite a lot of noise on the ML and having
some of
your trivial patches (e.g. replacing functions with FFmpeg defined ones)
merged into
one would help to decrease it.

>Currently I am trying to get rid of a
>lot of the last aspect to create a foundation for myself to work on
>other things.
Huh? What's so unclean about the current codebase that you simply can't
work on
anything else? Can you really not sleep at night if you know there's an
unchecked malloc
call (never a problem with a non-ancient OS) somewhere in an obscure 90's
video game
decoder which theoretically works but people lost the only available
samples 5 years ago?
What other things? Also be careful, the definition of a "foundation to work
on" could vary
between people. Hence a reason for reviews.

>Part of that defense (for me) is examining compiler warnings,
Many compilers (don't) warn about things that other compilers would. There
compilers
have versions which (don't) warn about some things that other versions do.
It's pointless
and conforming to a method that most compilers don't warn about can be
hacky and may
cause some compilers difficulty in actually compiling. It's best to choose
the absolute
least hacky way which works well with the newest (if sane, if not, newest
sane) version (!) of
the most popular compiler and doesn't emit a warning with the current "-W*"
arguments or
just keep the current status quo.

>fixing undefined behavior,
How does one fixed something undefined? Anyway, absolutely nothing wrong
with justified
undefined behavior, it's just working around the fact that:
>conforming to standards when possible
the standards are not that well defined or policed or sometimes sane (not
really the case with C) to
begin with. Rust wants to change that but it just takes away the fun of
programming (in C & others).
Any compiler which does something different than what other compilers do
under
undefined behavior which you rely on is in fact a not-very-sane compiler
and makes people
sad because if many people are stuck with that not-very-sane compiler it
means there is a
need for a special workaround for the not-very-sane compiler. Which then
encourages other
compilers to also have some other special way of doing undefined behavior and
thus bring more
ugly hacks. So yeah, sticking to the standard when possible is the best.

>From another email in this thread:

>None of these things are satisfying, but to be honest, I am not
>looking for satisfaction from FFmpeg.
So you're not finding your work satisfying, you're probably not getting
paid, you're bothering
yourself over getting other people bothered by your work, yet you still do
it? This is beyond logic.
I suggest you make your mind up and either find joy from doing something or
money or both.

>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
>in character.
You wrote this as if writing a job application; this is a mailing list of
equal adults (more or less)
interested in drama, popcorn and the development of FFmpeg, in that order :)
Though if you wrote this in a job application I'd hire you. Which is again
more or less what anyone
would do after they graduate: finding a job. Though nowadays there are
other alternatives becoming
popular: "finding yourself (by exploring the world)", "football!",
"NEETdom", "soccer", "FOOTBALL!",
"professional Quake 3 player", etc.

>av_gcd patches
>algorithmic improvements
Yes, your work on ff_ctz was very nice, kudos, I liked it.

On 30 October 2015 at 11:34, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:

> Hi all,
>
> Apologies for the length of the email, but there is a lot of stuff I
> would like to cover due to my absence on IRC or other venues for "non
> patch related" discussion.
>
> There has been a lot said and still being said regarding some patches
> I sent and associated discussion. Issues not related to patches in a
> technical sense are being discussed privately.
>
> In the meantime, I have noticed an increased level of hostility on
> ffmpeg-devel lately, both from my end as well as from others. I do not
> wish to escalate it further, and want to let work progress as smoothly
> as possible.
>
> In fact, I repeat a statement I made earlier: if overall people think
> that if I leave better and more work will be done for the project, I
> will gladly do so. That is the only thing I wish for: FFmpeg becoming
> better. To clarify a possible confusion on IRC: I by no means intend
> to work on Libav - either I work for FFmpeg, or not work at all on
> multimedia. This statement holds true regardless of what people
> express about the work I do here, whether I am kicked out, etc.
>
> The reason I repeat this question of leaving is because I dug through
> IRC archives, trying to understand better what people here think of
> the work I do in light of the increasing hostility on the ML. I got
> the sense that a lot of information that I could have received did not
> reach me as I am, and will not be on IRC. I also got the sense that
> there is a section of FFmpeg developers who are deeply against the
> kinds of things I do and the way I handle them, hence prompting the
> question.
>
> Assuming that you feel I give a net positive benefit to the project,
> please read on.
>
> I am quite puzzled with some of the sentiments expressed there. I
> illustrate below what puzzles me, and ask what I can do on my end:
>
> 1. "Sloppy" patches - I tend to give more verbose commit messages to
> explain rationale than many here. I also outlined why I did not post
> benchmarks initially. I myself still think they are unnecessary and
> not useful for many of my proposed changes, but the community here
> seemed to think otherwise. I have hence started posting benchmarks.
> I generally try to give evidence for things that are more "universal"
> in character when possible, so as not to skew towards any particular
> machine architecture, etc. I do not agree that the log patches were
> "sloppy" - bit accuracy improvements for log10 over log should have
> been obvious. Simplification of the code, a subjective aspect, should
> have been quite a reasonable assumption. Do people here not think such
> things are obvious?
>
> 2. "Increasing warnings" - There were only 2 instances AFAIK where I
> made a mistake, one in apedec. Another was in a test build. Both were
> very quickly resolved. These issues were tiny compared to the general
> level of warning cleanups achieved. Both were reasonable mistakes that
> missed the eyes of reviewers. Please do let me know when I do increase
> such things, I try to test things the best I can on my end. I will
> strive to be more cautious in the future by incorporating the lessons
> learnt with these two failures.
>
> 3. Patch sending mechanism - I have tried both approaches, namely an
> en-masse single patch, versus individual tiny patches. Both were
> frowned upon: the en-masse as "not fond of mass changes", and the
> single patches as "incredibly noisy". Regarding pinging, I pinged a
> single patch in a set of similar patches with a phrase regarding the
> fact that the ping extends to other such similar patches. This ping
> was ignored. I push (following the dev policy) one change after
> sufficient delay, and it was frowned upon. I did not know what to do,
> so I subsequently pinged each of the patches. This resulted in a bunch
> of comments on IRC. For reference, these are the av_warn_unused_result
> patches for avutil. Any suggestions for the future?
>
> 4. av_warn_unused_result not being useful en-masse for all headers -
> This was something remarked upon in IRC. I did not get this
> information in the form of reviews. Please suggest which headers to
> target first: I am currently just going one by one in a natural order
> (so that I can keep track of which ones have been addressed). Of
> course, if people think av_warn_unused_result is inherently bad, that
> is a separate issue that reflects an even deeper gulf.
>
> 5. General communication failures - Clearly, a lot of important stuff
> from IRC is not reaching the ML. I (and some others here) do not use
> IRC, and are pretty firm about not using it. What can be done to
> address the communication gap? I would have at least understood the
> deep hostility to the work I do if I had seen IRC logs a few weeks
> back. The ML got only the "effects" and little of the "causes".
> Overall, my sense is that people let the negative reaction bottle up,
> venting every now and then on IRC, since for whatever reason it is
> more comfortable, although technically both are publicly recorded and
> nearly as easily referenced in mails or commit messages. As a side
> note, even some patch review is done on IRC, a situation I do not like
> but have not raised so far as I am not affected by it.
>
> 6. General uselessness of the work I do - I agree a lot of work done
> recently has been towards "theoretical" issues, etc. However, in the
> past I have fixed tickets and cleaned up more "practical things" like
> unchecked mallocs. Even now, I do address integer overflows, etc. I
> have also done some performance optimization work at an algorithmic
> level. I have had discussions with Michael privately regarding
> optimizations. The reason I currently focus on "theoretical work" is
> as follows:
> a) Since it is scattered across the codebase, I get to see a variety
> of files and API's and get a feel for things.
> b) I feel that we have plenty of people who address new filters, new
> asm optimizations, new demuxers, etc. I focus on work that others are
> not willing or not interested in, so as to keep some balance. Quite
> naturally people do not like these things as much and it generates
> noise on the ML. I see no easy solution apart from avoiding such work,
> which I think is a bad idea overall.
> c) I viewed, and still view FFmpeg as a long term project for me to
> work on. As such, I do not mind spending 6 months - 1 year cleaning up
> the code in various ways.
> d) I prefer to be defensive with respect to C code. Part of that
> defense (for me) is examining compiler warnings, fixing undefined
> behavior, conforming to standards when possible, etc. FATE should pass
> before or after any of this, FFmpeg will continue to work fine
> with/without this stuff. Why bother then? It is mainly for
> sustainability and security reasons. The codebase continues to grow at
> a rapid rate. I consider the above work a useful "line of defense"
> against attack. By silencing warnings, new useful warnings/dangerous
> practices can be spotted more readily. By fixing undefined behavior
> etc assuring security of some components is easier. I thus think that
> this is very different from being a "K & R style guy". In fact, very
> few (or perhaps none) of my commits are reindents. There was the
> avfilter rename work which people did express some interest in (see
> Paul's commits) that I dropped quickly upon Stefano's remark. I did
> this solely because no one else would do it, though some felt it could
> be useful for consistency. In particular, I did not want "tribalism"
> in libavilter - Paul's filters using one convention, Clement's
> another, and so on and I expressed this reasoning publicly as well. If
> people feel I am a "K & R style guy", I will leave as I don't think a
> "K & R style guy" is useful for FFmpeg at the present juncture.
> e) I have no personal interest in asm optimizations (to address a
> suggestion on IRC). I do appreciate the hard work there, it just does
> not appeal to me for reasons that I can answer privately. I am
> interested in security aspects, algorithmic improvements, bug fixes,
> and clean up (in that order). Currently I am trying to get rid of a
> lot of the last aspect to create a foundation for myself to work on
> other things. Part of that transition is already under way - see e.g
> av_gcd patches as an algorithmic improvement.
>
> Please feel free to add things, send private email, or public
> questions so that we can come to a better understanding.
>
> Regards,
> Ganesh
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>