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

[Uoti Urpala]

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:
> > "The rules" being something which is not actually defined.
> > svn-howto.txt (which seems to be what people talking about "rules"
> > think contains them) neither has all the things claimed as "rules"
> 
> Yes, there are a few unwritten rules. Patch welcome.
> 
> > nor contains ONLY them.
> 
> And what's the big deal about it? Again patch welcome if you really
> feel that the POLICY / RULES section deserve a file on its own.

No I don't think it deserves a separate file. Trying to make it into a
legal document which strictly defines what is right and what isn't would
require a lot of effort and the result still wouldn't be good. People
just need to understand it is not such a document.

> > It has things nobody follows in practice.
> 
> Like? You are the only one who ignore those rules.
> 
> > 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 - the exact opposite of what is
wanted in practice. Other things which several people have done
differently without complaints are at least 5 (what was the last
complaint about a correct warning fix?), 7 and 9 (would likely have more
examples if the project had more people who work outside a limited area,
or if there was more code that is clearly "actively maintained").

> > 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, which probably
drove away most people who already had real experience about doing
things right. The ones who remained either accepted such practices or at
least came to regard them as business as usual. Since then the practices
(though not so much any written descriptions) have slowly moved towards
more normal ones.

>  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. And as I said I don't think any set of rules
could really capture good practices.

>  But stop wasting everybody's time by knowingly
> breaking the existing rules.

So how did I waste anyone's time? It's plausible that someone could have
a conflicting patch, but so far no one has mentioned that. That's a
common pattern among the cases where someone complains about "breaking
the rules": it's not that the commit prevented anyone else from doing
development, but it's the flaming about it that wastes time. 

So far my commits have overall improved MPlayer. The complaints about
not following traditional rules have not achieved anything positive.