overreacting (was: Re: [MPlayer-dev-eng] uau - svn account removal)

[Michael Niedermayer]

Hi

On Mon, Feb 26, 2007 at 12:12:14AM +0100, Diego Biurrun wrote:
> People,
> 
> where has everybody's sanity gone while I was away from my email for two
> days when my mail server was down?  This vote marks a low point in the
> history of our project and reminds me of times I had hoped were long
> past.

iam not sure what you mean, the only insanity i see is root not 
handling this like arpi did and by doing so cause everyone a whole day
of work, disscussion and cleaning up, and no i dont neccesarily mean
closing uaus account, but a clear and strong statement that such
behavior is unacceptable and that it will not be tolerated, your
attitude is very wrong IMHO

and dont missunderstand me this is critique on you as root not on you
as diego who is my friend :)


> 
> I was going to shout bloody murder at all of you, yet I have slightly
> calmed down now after talking to a few people on IRC.  I was going to
> let you have a glimpse of my turmoil by inserting a big rant here, but
> I have decided to delete it again.  This fire has clearly had enough
> gasoline.

i can assure you i also deleted quite a bit in several mails i sent today
some of that involved leaving the project


[...]
> So what has happened?  Uoti split some part off from mplayer.c's main
> function so that it ended up at a mere 1450 lines, which - given how
> long it used to be - should be a reason to unkork a bottle of the good
> stuff.  Let's please not forget this.  Therefore first off:
> 
> \o/

we all are happy about the cleanup but that doesnt exempt it from some
common sense


> 
> Now it was a big commit and it broke some pieces of MPlayer, namely the
> GUI and libmenu.  The former was known, the latter not.  I guess Uoti
> simply does not compile with OSD menu enabled.  I personally do not mind
> temporary breakage from large changes, it's just the way things go.  In
> the end - and this is what counts - Uoti fixed both.

the breakages are not what i complain about its the mess in svn created
by commiting >200k of code which are almost all cosmetic or moving
things to MPContext but there are a few other functional changes litterally 
hiden in it and no proper use of svn cp
if such changes are tolerated mplayer will soon be a trojanized application
as noone can or will review such changes for malicious code


> 
> Surely Uoti could have sent a patch before committing and give everybody
> else slightly more time to prepare for the big changes.  Would this have
> changed (much)?  I doubt it, big patches to the core have very little
> chances to get reviewed except maybe by Reimar.  Also, it's normal for

ive reviewed the whole cleaned up patch posted after the mess
ive not reviewed the mess in svn completely ...


[...]
> Some technical details of the commit were also criticized.  The new file
> command.c that was split out from mplayer.c could or should have been
> created with 'svn cp' instead of 'svn add'.
> 
> This is debatable.
> 
> svn-howto.txt is not at all clear in this regard.  After rereading it I
> found no part that clearly mandates this.  Others may disagree, but this
> only proves that it is indeed not clear.  Furthermore we have a precedent
> by Reimar who split out mpcommon.c from mplayer.c shortly before without
> using 'svn cp'.

and iam sure reimar will correct this


> 
> Uoti (re)formatted the new file to his taste, reindenting it, reordering
> includes and whatnot.  New files have always been formatted to the
> author's taste in MPlayer so I don't see a problem at all here.

command.c is NOT a new file its part of mplayer.c and yes iam happy
if its cleaned up but not in a single big functional and cosmetic mix
making review now and in the future in case someone tries to debug a
problem impossible

please diego, go and debug some bug before telling the developers
what is clean and accpetable and what is not, for example i have 2 h.264
streams which dont decode correctly anymore, ill debug this by
doing a binary search in svn as the alternative is 10 times more
work (and iam speaking from experience here and iam not exagerating)
if now my binary search would end on a 200k change i would have a
problem ...


> 
> Contrary to what some people believe this does not affect the diff
> appearing on mplayer-cvslog at all.  New files are shown in their
> entirety, always.  The commit notification program could be cleverer
> about this, but it just isn't.

well and our svn admin who hacks the repo for breakfast also should
know this better but he doesnt svn cp diffs are shown as diff 
against ther parent file of course this doesnt work if they are
reindented completely or the repo is inconsitant from some svn add->cp
change, you can check a past commit which was done with svn cp if you 
dont belive me


[...]
> I have a proposition to make in order to draw all of this drama to a
> close: nothing.
> 
> Seriously.  All the suggestions I have seen to fix the "mess" we are in
> will not make anything considerably better IMO.  The tradeoff between the
> time and work it takes to clean up and the (marginally if at all) better
> situation we will end up with is simply not worth it.  Furthermore,
> knowing the lot of us, I don't believe we can pull it off without
> generating more ill will, friction and flamage.
> 
> Just let it go.

as you dont even seem to know how svn cp works nor have read the changes
uau did i really think you jump to quick to suggestions also your attitude
does nothing to improve the quality of commits and patches


> 
> Uoti, please try to make more of an effort to keep everybody happy next
> time around.  It will be much appreciated and let my hair keep its color.
> 
> Before you jump at your $mailer and answer, please wait.  Have a night's
> sleep, let everybody's head cool down and think about what I had to say.

sorry, but i wont leave your nonsense here for a day especially not the
part on how svn cp works, you didnt wait a day either before writing it

btw, did you even read the code uau commited and the cleaned up patch?

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20070226/3103e9ea/attachment.pgp>