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

[Uoti Urpala]

On Sun, 2008-04-13 at 00:04 +0200, Aurelien Jacobs wrote:
> 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")

Don't be stupid yourself. The last sentence is a separate case where it
tells not to indent at all, not just in another commit. It clearly says
not to fix the indentation.

It was added by Arpi in 2002 - do you really think he thought back then
that up to 5 line mixed cosmetic changes were OK, and larger ones needed
to be separated?

> Anyway, if you really see someone breaking any of these rules, you are
> free to complain and ask him to revert commit.

"free" to do something idiotic. "Breaking rules" is never by itself a
reason to revert something unless there is a benefit to development.

> But that don't give your the right to break the rules yourself.

"The rules" being what the people used to vocally complaining if things
don't go their preferred way try to enforce.

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

You really think everyone else prefers the same "rules" as you? That all
other new developers just happen to have the same preferences?

Old developers like you are by far the most vocal complaining about
things that others do, often quite disproportionately to their current
activity. Who's the newest (to MPlayer) developer who complains about
"rule breaking"?

Most people will not argue back for long if the most vocal developers on
the mailing list argue they're doing wrong. They'll either avoid
conflict, believe that the flamers really are right (especially
inexperienced ones) or just quit.

That I disagree with your preferred development practices is not
something unusual. What is more unusual is that I haven't quit and
stopped improving MPlayer. The reason you don't have more people "like
me" is not that my disagreeing with you would be exceptional, but that
you've managed to drive most of those other people away.

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

If there is no disagreement there is little reason for trying to make
any rules binding.

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

And you conveniently blame the commit for that, not the flamers?

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

What gives you the right to insist on any "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)

An obviously correct commit, which should not be controversial to any
degree. To a file for which you're listed as the maintainer, but do very
little actual maintenance for. And you were "pretty angry" because of
this? And want the commit reverted???

Your position is so completely ridiculous that it's hard to take you
seriously at all. Can you even try to explain how following your wishes
in a case like this would benefit development - in fact, why it would
not clearly hinder development?

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

And you think your insisting on "the rules" does not drive away
developers or harm MPlayer?

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

So you think not agreeing with your rules is incredibly rude, but
insisting that everyone must precisely follow whatever you choose as
rules is perfectly fine and not rude at all?