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

[Michael Niedermayer]

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.


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


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


> 
> > Also you speak about this as a throw him out vs. keep him in the project.
> > If one looks at it like that it surely is better to keep him, but its not
> > so simple. its that >50% of the people do not get along with him and
> > loosing 1 vs. loosing 50% of the developers is something quite different
> 
> You assume that the majority (whatever that may be) shares your opinion.
> The majority is silent.  The longer I look at the situation, the less I
> feel confident to predict what these other people think.

start a vote if you want to know the truth, but then you do not want to
know it i think ...


> 
> It's also not as simple as you think.  I surely do not want to work on a
> project where valuable contributors get thrown out like this.  Of
> course, you have made it pretty clear above that you do not value my
> contributions.  If everybody else agrees with this then I do indeed not
> see much point in continuing to waste my time here.

Your contributions are valuable, but iives, ... are as well.
And you started wheighting peoples "worth", that is uoti is more worth than
roberto, aurel, me, iive and alban.
So if you feel depressed now, hell, the ones you indicated that they are less
worth than uoti feel likely as well.


> 
> > > 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
> 
> I am not denying this, but the question is what constitutes a hostile
> environment.  I'll quote Denes Balatoni, one of the innocent bystanders
> on the fringe of this project:
> 
>   I have not partcipated in the discussion before, but now that you
>   ask, I will say that IMO it is not wise to complain about some
>   ancient and not neccesserily consensual "cvs rules" by older inactive
>   MPlayer developers, just to get rid of a newer - but one of the last
>   active - MPlayer developer. I think a more forgiving and constructive
>   environment would better serve the interests of the project.
> 

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


>  Of course, FFmpeg can get away with it, 

away with what?


> 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


>  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



> 
> MPlayer cannot afford that luxury.  I want the constant flaming to stop.
> People should concentrate on coding and reviewing instead of shouting at
> each other.

So because the policy of "no flames, no deluser, no democracy" has driven
most away. You now argue that it should be continued?


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


> 
> 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.
I know several xvid developers are subscribed to mplayer-dev. Maybe one
will awnser it precissely in exchange of one of his patches being reviewed?


> 
> I find it very irritating that Ivan can get away with anything without
> attracting your wrath while others get attacked over much less.  This
> behavior is incongruent, especially in light of the actual contributions
> that Ivan and other people do.

Who have i attacked due to reverting a policy violation?
Or who have i attacked due to a change in capitalization in the docs?

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20080531/f1650199/attachment.pgp>