[FFmpeg-devel] possible farewell; dev policy clarification

[Paul B Mahol]

On 10/30/15, 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.

There is no plenty of people who address new filters, even less
people address new small decoders and demuxers and only one and half
who RE big stuff.

> 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.

I'm interested to know what is left to cleanup?

> 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.

There is another problem: increasing FATE coverage.

> 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.

I'm just going to tell you that you should ask before pushing something
that was not explicitly approved or even worse, was rejected.