[FFmpeg-devel] [FFmpeg-devel-irc] IRC log for 2010-09-30

[Michael Niedermayer]

On Fri, Oct 01, 2010 at 04:25:32PM -0400, compn wrote:
> On Fri, 1 Oct 2010 20:10:16 +0200, Michael Niedermayer wrote:
> >On Fri, Oct 01, 2010 at 09:46:52AM -0700, Jason Garrett-Glaser wrote:
> >> On Fri, Oct 1, 2010 at 8:16 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Fri, Oct 01, 2010 at 03:42:55PM +0100, M?ns Rullg?rd wrote:
> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> >>
> >> >> > On Fri, Oct 01, 2010 at 02:56:30PM +0100, M?ns Rullg?rd wrote:
> >> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> >> >>
> >> >> >> > anyway, this is really becoming a problem now slowly, you cannot every day
> >> >> >> > attack me with lies, insults or trolling behind my back on irc and still be a
> >> >> >> > member of the project, this is not at all a threat from me as leader
> >> >> >>
> >> >> >> I do not recognise you as a leader. ?A leader is someone who sets a
> >> >> >> good example for others to follow, someone other can place their trust
> >> >> >> in, someone who has been chosen, by voting or consensus, to be the
> >> >> >> leader. ?A leader is not someone who shows blatant contempt for the
> >> >> >> very rules he wants others to follow, nor is he someone who has
> >> >> >> simply assumed the title.
> >> >> >
> >> >> > Iam always trying to follow the rules i expect others to follow.
> >> >> > Its you who does break the rules continuously and claim others break them.
> >> >> > Just your commit 1 minute ago r25286 is a good example
> >> >> > you make whatever change you want to code actively maintained by others and
> >> >> > even though a discussion and disagreement exists at the very time.
> >> >> > Rule or not its expected to discuss controversal changes especially if the
> >> >> > maintainer is against them before commiting.
> >> >>
> >> >> Fixing a forgotten #include is hardly controversial.
> >> >
> >> > its not forgotten its unneeded and i said so
> >> > common.h includes several headers and these do not need to be included
> >> > everywhere.
> >> > But that was just one commit, there was the 1->3rd person change (full of
> >> > bugs due to the automated replacing you did) never approved by anyone and
> >> > never posted for review. and the removial of part of the symbol versioning
> >> > documentation against the explicit wish of the maintainer. And thats just
> >> > what i remembetr atm.
> >> > not to mention threatening people with closing their accounts and closing
> >> > jasons account.
> >> 
> >> Just because Mans does stupid things doesn't exempt you from public
> >> discussion of your patches before they are committed.
> >
> >no but IMHO this change didnt need more public discussion
> >The assert issues have been discussed a long time ago with IIRC very low
> >interrest by people, this also means the basic design has been discussed
> >previously and there was noone against ...
> >and it was changes to code i maintain (libavutil) and i had and have no reason
> >to belive anything of it being controversal. And in such cases "the rules"
> >say commit without patch is ok, this has always been done that way, the
> >maintainers can change their code without patches if theres no reason
> >for them to belive that anything is controversal.
> 
> if this broke compilation somewhere it'd be nice for someone to paste
> it so that we can end this dumb argument quickly.
> 
> only thing i can find is that it broke linking in mplayer
> [23:55:29] <Dark_Shikari> 09:55 < ubitux> revision 25278 has introduced
> some linkage error: ffmpeg/libavutil/libavutil.a(mathematics.o): In
> function `av_rescale_rnd' << undefined reference to `assert'

This seems a bug in the MPlayer build system
it builds libavutil from within the directory and uses -I.
and without -I- that way the local directory will be used to search for
#include <...> headers
this seems quite incorrect behavior to me

diego?


> 
> you both are fighting over some really dumb things.
> 
> mans has a problem with too short commit messages

commit messages are easily fixed


> mans has a problem with michael committing without patch

> michael has a problem with mans committing without patch

i have a problem with people commiting to code iam in the very moment
actively working on and while the issue is being discussed and the
commit in question was rejected by the maintainer and author.


> michael has a problem with mans complaining on irc instead of ml

I have a problem with untrue statements about me, like claims about
rejected patches or what my definition of anything is or what i assume.
This harms the project as well as people get the wrong view of how things
are done.


> 
> i realize you guys cant agree. and both of you want ultimatums. but
> can you compromise? e.g. mans will only comment on michael on
> the list, and michael will post patches before committing ? is that
> fair?

i ve compromised since years, and the situation has only worsened


[...]
--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101001/cc1c7e98/attachment.pgp>