[MPlayer-dev-eng] [patch 02] Fix stream_ffmpeg read near EOF (was: mplayer fails to seek large file (>2G) over http due to misparsed Content-Length)

Uoti Urpala uoti.urpala at pp1.inet.fi
Sat Jan 23 10:55:51 CET 2010


On Fri, 2010-01-22 at 19:58 -0800, RC wrote:
> On Fri, 22 Jan 2010 08:42:04 +0200
> Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> 
> > I don't know how familiar you are with the project politics
> > surrounding the two repos. In case you haven't seen it, the following
> > mail tries to give some information about the overall situation:
> > http://lists.mplayerhq.hu/pipermail/mplayer-users/2009-December/078521.html
> 
> Actually, if you really want to know what's going on, you have to go a
> ways back to get the full story.  I recomend Michael's explanation of
> the subject:

If you believe you can give a more objective view of the situation, you
should be able to do better than link to old _flames_.


> Michael Niedermayer wrote:
> > uoti has lost svn write access to ffmpeg

In the beginning MPlayer and FFmpeg access were shared. Michael refused
to accept that I did development differently from what he preferred. He
couldn't get my access to the MPlayer repo closed, but still insisted on
giving some kind of petty display of disapproval. Thus he had the access
control separated so he could get my access to FFmpeg removed (even
though I was neither using it nor going to use it anyway).

> > In the end you are where you started, uoti commits what he wants no
> > matter if its a 80kb patch which he thought was just a reindent or
> > some unapproved change to files activly maintained by others ...

Not a very objective description. RC, did you really honestly think
quoting a flame like this would be giving "the full story"?

> > He does not agree with the idea of some kind or private space for
> > maintainers nor about spliting patches if it means extra work to him.

In more neutral terms, "private space" here means a kind of strict code
ownership. Yes I do think the way he wanted to do that was a bad idea.
And yes I do disagree with the old MPlayer patch splitting practices (as
does almost every other project).

> > And especially (and i think this is worst) he does not care at all if
> > others complain about his actions and ask him politely to revert.

He and some others would have preferred a situation where I do the
actual work and they tell me how to do it while doing little work on
MPlayer themselves.

> You might also try:  [MPlayer-dev-eng] uau - svn account removal 

Which contains mostly flaming (related to Michael's above-mentioned
attempt to get my MPlayer svn access removed), from people who had
little to do with actual MPlayer development back then and even less
now. What do you think that has to do with the current situation?
Anything beyond "there were flames before"?




More information about the MPlayer-dev-eng mailing list