[MPlayer-dev-eng] uoti

[Michael Niedermayer]

Hi

On Wed, Feb 28, 2007 at 06:06:30PM +0200, Ivan Kalvachev wrote:
> 2007/2/28, Michael Niedermayer <michaelni at gmx.at>:
> >Hello commrades
> >
> >ive had a long disscussion with diego on the phone, about the mess,
> >uoti, the voting, policy, and other things
> 
> I don't like phone discussion, mainly because they don't provide you
> with enough time to check the facts.

certainly but they help alot in better understanding the other person
and his motives which rarely match the results achived ...
also diego did not try to twist the facts, policy is unclear


> 
> >ive agreed with him that uoti shall keep his mplayer svn account
> >currently the reasons behind this are
> >* svn policy is unclear about svn cp, actually it doesnt even mention
> >  svn cp, its mentioned in other places yes but not directly in the
> >  policy so screeming policy violation due to lack of svn cp isnt
> >  entirely true, the policy definitly needs to be improved to clarify
> >  such things like svn cp, so this is clear for everyone!
> >* also claiming uoti should have send a patch due to policy is another
> >  unclear area as he was maintainer though it can be argued that it
> >  must have been clear that the change would be controversal and that
> >  he thus would have had to send a patch but again this is a little
> >  fuzzy and not clear
> 
> Uoti is not mplayer.c maintainer and the code he had committed does
> not relate to a-v sync:
> 
> *tech/MAINTAINERS
> A-V sync code, MPlayer core: Uoti Urpala

well but what is "MPlayer core"? is mplayer.c part of it?


> 
> 
> *tech/svn-howto ,
> Basics:
> #8 [svn copy/move]
> To split a file, use 'svn copy' and remove the unneeded lines from each 
> file.
>  Don't do a lot of cut'n'paste from one file to another without a
> very good  reason and discuss it on the mplayer-dev-eng mailing list
> first. It will make those changes hard to trace.

yes thats what i meant its not in the svn policy but in "I. BASICS" not in
"II. POLICY / RULES"

if I. basics where part of the rules why is II. called Policy/Rules ?
this is something which should be changed ...


> 
> Rules:
> #1 (Do not commit broken code).

and did he commit code from which he knew it was broken? i think not
and #2 says "You don't have to over-test things. If it works for you,
and you think it should work for others, too, then commit"


> #3 (Do not commit unrelated changes together, split them into
> self-contained pieces).

the question is what is unrelated, there should be examples in the
policy


> #6 (cosmetics)

i agree that he violated that but you could argue that this only
aplies to changes and not "new" files


> #12 (Always send a patch to the mplayer-dev-eng mailing list before
> committing  if you suspect that the change is going to be
> controversial.)
> I'm not even arguing about #9 (code maintained by others).

mplayer core was maintained by uoti at the time of commit


> 
> I don't see anything fuzzy and unclear. Even one break of the rule is
> enough reason to revert.

yes, the change was bad it should have been split in seperate changes
cosmetics should have been split off, uoti should have sent a patch, ...
theres no question about that, its just that policy is not clear about
this and yes it should have been and will be reverted but the question
is should uotis account now be closed or not


> 
> 
> About the vote.
> If there is problems with the counting we can always repeat it. It
> must be public as I have no idea if my vote to root@ have been counted
> at all. (actually we never got to hear the exact results).

my vote is revert/cleanup the mess and close uotis account if this happens
again and clarify policy so it cannot be missunderstood also make it
clear that policy violations will lead to first a warning and by repeating
will lead to account suspension

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070228/33f28043/attachment.pgp>