[FFmpeg-devel] [PATCH] Add versioning information to dlls

[Baptiste Coudurier]

Ramiro Polla wrote:
> M?ns Rullg?rd wrote:
>> Ramiro Polla <ramiro at lisha.ufsc.br> writes:
>>> M?ns Rullg?rd wrote:
>>>> I never approved this change.
>>> Of course not. You ignored it, like you always do if the patch isn't 
>>> something trivial or if you can't spark a flame out of it. You even 
>>> ignored the message when I said I would apply it. Now don't you come 
>>> with this "I never approved it" thing to try and clean your hands... 
>>> You're just as responsible for ignoring it.
>> Now who's sparking flames?  As for "ignoring" the patch, please allow
>> more than a few hours before committing major changes (and this was a
>> major change) to areas you do not maintain.  I don't receive email by
>> a direct satellite link into my brain.
> 
> ----------------------------------------
> [FFmpeg-devel] [PATCH] Add versioning information to dlls
> Ramiro Polla ramiro at lisha.ufsc.br
> Thu May 22 20:56:09 CEST 2008
> 
> Then send an updated patch with the simpler license_str and no trailing
> whitespaces and I'll apply it on the weekend if noone objects.
> ----------
> [FFmpeg-devel] [PATCH] Add versioning information to dlls
> Jeremy Kolb jkolb at wsi.com
> Thu May 22 21:27:19 CEST 2008
> 
> This should take care of the trailing whitespaces.
> ----------
> [FFmpeg-devel] [PATCH] Fix decoding of ffv1 when compiling with icc
> M?ns Rullg?rd mans at mansr.com
> Fri May 23 23:01:25 CEST 2008
> ----------
> [FFmpeg-devel] [PATCH] Some IWMMXT functions for libavcodec #2
> M?ns Rullg?rd mans at mansr.com
> Sat May 24 18:53:47 CEST 2008
> ----------
> [FFmpeg-devel] [PATCH] Add versioning information to dlls
> Ramiro Polla ramiro at lisha.ufsc.br
> Sun May 25 15:14:16 CEST 2008
> 
> Applied.
> ----------------------------------------
> 
> Sorry, but I consider this ignoring...
> 
> And from the development policy:
> #  Do NOT commit to code actively maintained by others without 
> permission. Send a patch to ffmpeg-devel instead. If no one answers 
> within a reasonable timeframe (12h for build failures and security 
> fixes, 3 days small changes, 1 week for big patches) then commit your 
> patch if you think it is OK.
> 

This patch seems big to me. You should have wait at least 1 week, and
ping several times before commiting, it's not like Mans is inactive.

Furthermore I'd like to note, that you broke something, and you should
have reverted it if you couldn't figure how to fix it quickly.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA