On Fri, Oct 30, 2015 at 8:42 AM, Paul B Mahol <one...@gmail.com> wrote: > On 10/30/15, Ganesh Ajjanagadde <gajja...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel