[FFmpeg-devel] possible farewell; dev policy clarification

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 8:42 AM, Paul B Mahol <onemda at gmail.com> wrote:
> 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?

Depends on how you view it, it is inherently subjective. I am sure
there are lots of things of varying degrees of importance. Concrete
examples of what I mean that I consider reasonably useful, and are
chiefly in libavfilter since that is where most of your work is:
1. The avfilter query formats CID's and the commit I made. I doubt
these were the only such example of lack of return code checks.
av_warn_unused_result is an effort to address such things.
2. Replacing some float's with double in libavfilter - noise floor
should be kept as low as possible unless there is a good reason
otherwise. I forget which files have this.

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

That is a very important problem in my view. I outlined some fuzzy
ideas regarding fate-perf, maybe we can have a fate-fuzz for e.g
mutations of input files on the lines of Google's fuzzing effort? All
such things sound like good GSoC/Outreachy candidates if they can be
made concrete.

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

Most, and perhaps all of them boil down to misunderstanding. This will
hopefully improve over time. I apologize to all who did not like
recent pushes from me. In fact, I can freely let go of my commit
access if these were deemed sufficiently out of line - I do not ask
for a formal "DECISION" or vote.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel