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

[Michael Niedermayer]

On Mon, Nov 05, 2007 at 04:16:25PM +0200, Uoti Urpala wrote:
> On Sun, 2007-11-04 at 17:45 +0100, Michael Niedermayer wrote:
[...]
> > 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. 

yes, as long as they match your idea of correct ...


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

like the uniform style of not mixing statements and declarations, ohh wait
that doesnt count because you disagree with that
or the asm style which is compatible with most compilers ...


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

idiocy like breaking gcc 2.95 support? like commiting unreviewable changes?
yes its similar you have my agreement


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

if we had #ifdef GCC295 in every function id vote for droping that support
at once as well, but thats not the case


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

so is breaking gcc 2.95


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

hmm, you seem to somehow think that i want a rule for everything, i think
you missunderstood me, that was not really my wish

diego had argued back then that he cannot take action against you as you
are a new developer and were not aware of the "rules" and they are nowhere
clearly written down
i wished to change that so there wouldnt be any further misunderstandings
and so that all new developers would be clearly aware of what would be ok
and what not, even if most of these rules would be completely obvious to
everyone.
i certainly dont think that having a long overly precisse rule list is
good but its better than the example above that is of a commit war and
no action from the admins because there wasnt a rule which gave them the
power to take action

also i think our policy does say that people cant randomly commit to 
code they dont maintain

either way, i dont have much interrest in this discussion theres not even
a real reason for it, other volunteers fix the gcc 2.95 breakages you
cause (that also defeats most of the advanatges you claim the mixing of
statements and declarations have because they arent there anymore) and besides
the gcc 2.95 breakage your commits where mostly well split, at least
much better than that mplayer.c change
so theres not much for me to complain about ATM

also iam not root so even if your commits wherent ok i couldnt do anything
anyway

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20071105/7ea15ac9/attachment.pgp>