[MPlayer-cvslog] r26411 - trunk/libmpdemux/demuxer.c

[Diego Biurrun]

On Sat, May 31, 2008 at 12:58:02AM +0200, Michael Niedermayer wrote:
> On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
> > On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
> > > On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote:
> [...]
> > > > We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for
> > > > Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin,
> > > > Diego).  This is a far cry from a clear situation, especially given that
> > > > each of the latter 4 is more active than all of the 5 combined.
> > > 
> > > Its true for the current activity but if i look at all commits of all
> > > times i much rather loose all of the later 4 than a single one of the
> > > first 5.
> > 
> > I think your anger is clouding your judgement.  You should try to
> > reevaluate the contributions of all nine people mentioned above.
> > 
> > I very much respect all the developers listed above, 
> 
> Of course ... if anything i said sounded like i did not then this certainly
> was not intended.

If your statement above was not intented to be disrespectful, then I
must say you failed catastrophically.

> > I know most of them personally, like them and the feeling is mutual.
> > Nonetheless nowadays MPlayer is being developed by a new generation
> > of people. That does not mean that the contributions of those people
> > are insubstantial or that not appreciated.
> 
> Yes but it also does not mean that the experience the "old generation" has
> collected over the years should be ignored like it is. The people not being
> against uoti are new people who do not yet have the same
> experience reimar, roberto, iive, ... have in respect to maintaining a
> large project with many developers working, joining and leaving ...

Reimar never spoke in favor of removing Uoti.

> If the "old genration" says mixing cosmetics and functional changes causes
> problems why would anyone think it is not so?

You are completely exaggerating.  The example that we are discussing
here is trivial.  The thing in front of your eyes is a fly, not an
elephant.

> Becasue the always better knowing uoti said it? On which big project
> has he worked in the past so he could even have that experience?

Which other projects have you worked on, BTW?

Note that one of the reasons Loren Merritt keeps x264 out of FFmpeg is
that he prefers mixing cosmetic and functional changes:

http://akuvian.org/src/x264/why_x264_isnt_part_of_ffmpeg.txt

I'm not saying that I support the position, but the assumption that no
competent and reasonable programmers hold that point of view is false.

> Or the same about commiting with no warning to code actively maintained
> by others. Even if one ignores what the "old generation" says, just looking
> at the recent months shows how such commits get everyone near boiling.
> Even you go crazy if iive just changes xvids spelling.

I did not "go crazy".  I'm old enough to be able not to freak out over
such silly provocations.

> What if i did the same with indexes/indices? IMHO that change made absolutely
> no sense, both are correct and there was no need to clobber the history.
> Wouldnt you have been angry as well if someone (maybe iive) would have just
> reverted it?

The opposite happened.  People expressed their concern in a calm and
reasonable tone without jumping to action.  I have absolutely no problem
with that.

> If you agree that a little bit of communication before commiting to code
> maintaned by others would be good then why is uoti apparently exempt from
> this rule?

Communicating every trivial change like adding a const or changing
spelling is an unnecessary burden.  We have countless precedents for
committing such changes right away without previous discussion.

> > But you could go further back in history and find
> > people that have done even more, like Nick and Arpi, yet are not
> > steering this project any longer.
> 
> it would be great if arpi would return and lead mplayer once again.
> The project really decayed after he left, back then noone complained about
> the too low manpower, because it wasnt too low ...

Your memory is a bit too rosy.  Arpi left MPlayer after realizing that he
had constructed an unmaintainable monster.  His attempt to rewrite it
failed.  And even back then many many patches fell through the cracks.
Arpi himself complained about the lack of help he was getting when it
came to reviewing patches.

> > Note that many many outsiders consider the environment around FFmpeg
> > very hostile.
> 
> Note that many many pigs consider birds ugly.
> no i have no evidence but neither do you.

It seems that you move in FFmpeg-related circles only then.  I have
talked to people from many other multimedia projects and distributions.
FFmpeg is very often viewed as a harsh and difficult environment with
which communication is not easy and flames abound.

We are making progress in the right direction, but we can still improve.

> >  Of course, FFmpeg can get away with it, because there is
> > no alternative to it and it holds a monopoly on its "market".
> 
> *GPL software cannot hold a monopoly, it can always be forked

A fork has to be able to survive and the benefit of forking has to
outweigh the costs.  This is not the case for FFmpeg, which is very much
alive with competent and active developers that are not easily replaced.

Also, no viable alternative to FFmpeg exists.  If you don't like
MPlayer, you can choose vlc or xine instead, like Mike did when he got
fed up with Arpi.

> > So people are willing to put up with more hardship or simply are
> > forced to work with FFmpeg one way or the other because they cannot
> > switch to an alternative.
> 
> You should probably post a detailed list of what you think can be improved
> to ffmpeg-dev

I'm working on it all the time when I am in contact with other projects
at LinuxTag, on IRC or wherever.  You may have noticed the Debian patch
I forwarded to ffmpeg-devel.  I have been working with the new FFmpeg
Debian maintainer these past few days reviewing their patchset.  With my
help he could determine that half of the patches are no longer necessary
and delete them.

> > > id like to point out how you complained about iive changing the
> > > spelling of xvid. Which honestly is totally irrelevant compared to
> > > changes to the code.
> > 
> > I did not complain about Ivan changing the spelling.  I complained about
> > Ivan reverting my commit without prior notice.  If he had reverted just
> > the files he maintains - fine.  But he chose to revert the files I
> > maintain as well.  He did it on purpose.  This is obviously a
> > provocation.
> 
> hypocrite ...

WTF?  Have we descended towards throwing around insults already?

> > How come that you don't have an issue with such behavior?
> 
> Lets see.
> * I do not know at all if Xvid or XviD is more correct. I do know it was
>   XviD once in the past so this one can not be completely wrong now.
> * You changed the spelling to Xvid in files maintained by you and ivve
> * iive changed the spelling back to XviD in files maintained by you and ivve
> * he did the same you did, you started
> * you broke the policy he reverted the commit which broke the policy
> No the whole was not ideal but nothing bad happened we are just back at the
> start and have another chance to find a solution. If the spelling bothers
> you. Just start a discussion on mplayer-dev about it, like it should IMHO
> have been in the first place already.

Are you seriously suggesting that we should waste time on dev-eng
discussing which way to spell Xvid?  When this was hashed out and
committed to the rest of the documentation in 2006?

Are you seriously suggesting that I broke the policy by changing the
spelling and, assuming that I did, it is OK to remedy that by breaking
the policy again, i.e. two wrongs make a right?

There was no previous indication that Ivan opposed the change and no
time for me to react.  At the same time it was obvious to Ivan that I
would oppose him reverting my commit, at the very least for the files I
maintain.  Ivan chose to ignore that, making his course of action a
needless trollish provocation that could lead to a commit war.

How come you do not have an issue with this kind of behavior?


The problem I have with you here is that you are applying double
standards.

On the one hand you insist on the strictest possible interpretation of
the policy for issues that you care about like separation of whitespace
changes from other types of changes and demand draconian punishments for
offenders.

On the other hand you are very lax yourself about issues you consider
less important like adding full license headers to files or updating the
documentation to match your code changes.  You have behaved this way
long before this incident, don't tell me it is a result of it.

That you then go on to call me - the person that goes out of its way to
split commits to your liking, writes the documentation for you, etc. -
a hypocrite is galling and does add insult to previous injury.

Diego