[MPlayer-cvslog] r24941 - trunk/mplayer.c

Uoti Urpala uoti.urpala at pp1.inet.fi
Mon Nov 5 15:16:25 CET 2007


On Sun, 2007-11-04 at 17:45 +0100, Michael Niedermayer wrote:
> i think the correct way to phrase it would be
> "iam the law, only my oppinion counts, and i consider that what the majority

> i really would love to see 2 or 3 uotis to have mplayer svn write access
> it would nicely show how absurd and unpractical this view is in a larger
> group

Having more people like me would not cause problems like you claim (more
about your claims of specific problems below). I do not try to make
everyone else work the same way I prefer to or dictate what they should
do. On the other hand having even two people with your attitude active
in the same project simultaneously would almost certainly not work. You
not only work the way you want, you insist on having strict rules on how
others may work too. Two people with your attitude could not work in the
same project unless they came from a very similar background and
insisted on the same set of rules. Maybe your view of projects has been
so limited that you've come to believe the rules you want to work by are
universal and would be accepted by all similar people. In reality two
people with your attitude but somewhat different background experience
would most likely find each other insisting on totally unacceptable
rules.

> but the part you completely ignore is that if you contribute to a project
> you have to follow the rules that project has and noone who works on the
> project will agree with every rule, if now everyone ignores the rules
> then quickly things will turn into a mess

Projects do not need strict rules in the way you seem to think they do
(based on your policy proposal for example). A lot of things work better
informally. Sometimes certain things are clarified by rules, but it is
still quite possible to have rules that everyone agrees with. Note that
"agrees with" is not the same as "matches most preferred way"; for
example a rule about a about common indentation style which does not
match everyone's preferred style but which the developers accept is not
inherently worse than their "own" style and is worth following to have a
uniform style.

Having rules which developers genuinely disagree with, in the sense of
thinking that they can not be logically justified, should not be the
considered the normal case.

> you would drop gcc 2.95, 3.* support (due to your mixing of declarations and
> statements as well as the asm sytax you use)

Which asm syntax do you mean? The one in the cabac.h patch I posted
last? I don't remember it having any explicitly 4+ syntax, though I
haven't tested whether 3.x would actually compile it correctly.

> now maybe i dont like gcc 4+ and would commit code which breaks it, hey
> why not gcc 2.95 IS supperior

Breaking gcc 4+ would not be "ignoring the rules" (no project should
need an explicit rule against things like that), it would be just
idiocy.

> a few other people would think that macosx and win32 support are against their
> free OSS philosophy and would thus break them

Intentionally going out of your way to break support which wouldn't
affect you otherwise is very different from not willing to work in a
limited subset of the basic language to support an obsolete compiler. If
macosx and win32 support were implemented in such an invasive way that
most functions everywhere would have #ifdef WIN32 blocks then I'd
actually understand people not willing to keep updating those when
they'd change the functions.

> next someone would remove all asm because that is not clean, high level
> code is always better and its the compiler job to optimize code

That's also in the "simply stupid" category.

> then 2 developers would start a commit war about reindenting the code
> for 4 or 8 space indention

And which rule would prevent this? If they both actually actively work
on the code and both find the "other" indentation significantly harder
to read then there is no easy solution, certainly not one that could be
set as a simple rule. You could have a rule like "try to avoid a commit
war even if you can't reach agreement", but if the people in question do
not already think so then having it as a rule is unlikely to help much
when the situation arises.




More information about the MPlayer-cvslog mailing list