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

[Uoti Urpala]

On Sat, 2008-05-31 at 00:58 +0200, Michael Niedermayer wrote:
> On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
> > 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 ...

I see no basis for a claim that older MPlayer developers would generally
be better in skills specific to large projects. Also that has definitely
NOT been a strong point of MPlayer historically. There have been
developers with enough skill to hide most visible breakage (or patches
from users) but IMO it's ridiculous to claim that MPlayer would have any
tradition of good architecture design/refactoring or efficient
cooperation between developers.

> If the "old genration" says mixing cosmetics and functional changes causes
> problems why would anyone think it is not so? 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?

No need to bring personal experience into that argument. You can look at
other projects directly and see that they do not follow the kind of
policy you want.

You're also misrepresenting what the difference in opinion is. If you'd
ask people "is it good to mix cosmetics and functional changes?" many
would answer "no". They just wouldn't mean that as literally and with so
little room for common sense as you do. Completely reformatting a file
and doing bugfixes in the same commit is bad. Readjusting a couple of
table rows when adding the word "static" in a commit labeled "Make table
static" is good. Redundant commits are harmful and so pointless
splitting should be avoided when the change is already obvious. Even in
cases where a commit could in principle be improved using a lot of time
to polish minor details is not a worthwhile activity when there are lots
of real problems to fix in the code. You're paying far too much
attention to a minor detail while ignoring more significant things.

> 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.

s/everyone/mostly people who do little useful work/. And that's a
circular argument anyway: you overreact to something, then argue "look
it WAS really bad, it made me totally overreact!".

The people who want to remove me from the project do not "actively
maintain" any code, especially not demuxer.c or demux_mkv.c (even if
still officially listed in MAINTAINERS).

> Even you go crazy if iive just changes xvids spelling.

You're either being stupid or deliberately misunderstand. Obviously
Diego would not have reacted that way if Ivan had just made to commit to
change it to any consistent spelling before Diego's changes. What Iive
did was revert changes Diego had just made. Iive can hardly claim to
know the correct spelling with superior authority, had not been working
on any related changes himself, was not directly affected by the
changes, and there was no hurry to resolve the matter. It was obvious
Diego wanted the other spelling as he had just changed it that way. Yet
Iive changed the spelling back without any discussion, not even flaming
that would have indicated there would be no agreement.

Who maintains that code was not the issue, except that it showed even
Iive himself doesn't in practice follow the rules he insists on.

> > > > This projects has many problems, but renegade commits are not one of
> > > > them.  Lack of manpower is much more serious
> > > 
> > > Well frankly the lack of manpower is caused by the hostile environment IMHO

If you're trying to imply that I would be responsible for the problems
remember how I joined the project. I fixed some nasty longstanding bugs
in the central timing code that apparently no existing developer
understood. You can hardly claim that those old developers who now want
to throw me out would have been doing fine before I joined.