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

[Aurelien Jacobs]

On Sat, 12 Apr 2008 23:55:03 +0300
Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> On Sat, 2008-04-12 at 21:12 +0200, Alban Bedel wrote:
> > On Sat, 12 Apr 2008 20:52:31 +0300
> > Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > > It's easy to accuse anyone you want if everyone breaks some "rules"
> > > and you can pick which to enforce.
> > 
> > You might want to read the rules section again. I see nothing in there
> > that is selectively enforced.
> 
> The most obvious example is the "NOTE:" part of paragraph 6, which tells
> to leave files incorrectly indented

Don't be stupid. It's absolutely not what paragraph 6 says !
(notice the: "if they are mixed with functional changes")

Anyway, if you really see someone breaking any of these rules, you are
free to complain and ask him to revert commit.
But that don't give your the right to break the rules yourself.

> > > Talking about "the rules" is nothing but an appeal to authority when
> > > you mean "this is different from how I'm used to doing things / like
> > > things done".
> > 
> > No, it's a set of things the team agreed upon.
> 
> Arpi originally enforced horrible development practices

IIRC, those rules where modified and improved far after Arpi's retirement.
And AFAIK, all developpers but you do actually agree with those rules.
Could you name a developper who disagree ?

> The ones who remained either accepted such practices or at
> least came to regard them as business as usual.

I accepted them and followed them because I think they make sens.
They can probably be improved, but they can't be disregarded.

> >  They can be changed any
> > time. If you don't like something just submit a patch and have it
> > discussed on the list.
> 
> There is no procedure for resolving any disagreements in case people on
> the list do not agree.

Common practice is to try getting a compromise. If this doesn't work,
the majority get to decide.
But why are you thinking about disagreements ? If your propositions
are good, there won't be any disagreement !

> And as I said I don't think any set of rules
> could really capture good practices.

Fine. Then propose a patch removing all rules...

> >  But stop wasting everybody's time by knowingly
> > breaking the existing rules.
> 
> So how did I waste anyone's time?
> [...]
> it's not that the commit prevented anyone else from doing
> development, but it's the flaming about it that wastes time. 

Any commit breaking rules will generate flames. You know it
very well, for having tested it many times.

> So far my commits have overall improved MPlayer.

That, most people don't disagree with.
But that don't give you any right to break rules.

> The complaints about
> not following traditional rules have not achieved anything positive.

This was supposed to achieve one goal: making you comply to the
rules. Unfortunately this wasn't successfull.

BTW: you broke rules 6 and 9 in your recent commit to demux_mkv
(which I maintain). I was pretty hangry seeing this. But I didn't
even bothered to reply because I know there's no hope getting you
to cooperate. (Note that you can still show your good will by
reverting this commit)

What you seem to achieve best is driving developpers away from MPlayer.
Yes, even if you actually improve MPlayer, I think that overall, your
are harmfull to MPlayer.
I would be happy if you would either:
a) accept to follow strictly the rules, and revert your commit
   when someone notice you broke a rule
b) voluntarily renounce to your svn account

If you don't choose any of them, then I would support any request
to drop your svn account.

Sorry to be rude, but I think no one can be as rude as your commits.

Aurel