[FFmpeg-devel] possible farewell; dev policy clarification
derek.buitenhuis at gmail.com
Fri Oct 30 14:40:05 CET 2015
I'll chime in on a few points.
On 10/30/2015 11:34 AM, Ganesh Ajjanagadde wrote:
> 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?
I am sorry to say, this comes off as a bit arrogant. The onus of proving
a patchset's worth is on its author, and "it's obvious" is not a valid
reasoning. There's no reason to be offended when asked to defend a patch's
value; it's one of the main reasons for reviews in the first place.
> 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?
One thing you could do is provide a little more rigorous testing / investigation.
Example: Making sure libm.h was included everywhere where log10 was used.
Part of the reason people got a bit annoyed is that they are large changesets that
are easy to write, and tedious to review and confirm correct. Providing some info
to that aspect in the cover letter, for example, can go a long way.
> 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.
Valid point, yes.
I do think it is beneficial to have real-time conversation to discuss changes,
sometimes, however. Summaries should probably sent to the ML, though, for
Overall, I think you may be too defensive of your own code / ideas sometimes.
That's understandable, but it's important to not take critical reviews so harshly,
More information about the ffmpeg-devel