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

[Diego Biurrun]

On Mon, Feb 26, 2007 at 01:26:47AM +0100, Michael Niedermayer wrote:
> 
> 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

We have different ways of achieving the same goal.  I consider this
whole voting procedure a mistake.  I've been on the phone with Attila
yesterday and he has deep regrets about having kicked off this
avalanche.

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

Good :)  The feeling is mutual.

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

That makes two of us.  I was also at this stage at some point, even
though for a different set of reasons.

IMO this shows that we're all overreacting and should think all of this
over with more of a cool head.

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

Nobody is claiming that, but I feel that the notion that this was a very
very remarkable event has been completely obliterated over all the noise
and I wanted bring it back to attention.

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

I'm not claiming that the commit was perfect, nor that I would like to
see more of it again in the future.  We agree completely in this regard,
I just consider the path you are going down to achieve this (common) goal
very very wrong.

I don't agree about the trojanization, but this is leading us offtopic,
so I will not get into it.

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

This seems to be a funny side-effect of the whole thing, the code has
been scrutinized much more closely than it would otherwise have been.

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

IMO Reimar recommitting this was unnecessary.

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

The problem is that we do *not* have clear rules in the policy about
this.  Hanging somebody for not following laws that are not precisely
spelled out is completely unacceptable for me!

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

Trust me, I have done my share of binary searches for bugs in my time.

If you look at my commits, they are always split into the very smallest
parts possible and this has often cost me extra time.  Whether I have
the right to demand this from others I am not sure.

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

Yes, sorry, I'm talking complete nonsense (and I do of course know
better).  'svn diff' does not show it, but the commit notification
program is cleverer.

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

This voting procedure does nothing to improve the quality of the commits
and patches either IMO.

Much more importantly, it most surely does nothing to improve the
quality of this project nor to make it a place where devs can feel
welcome and collaborate effectively.  I'm thinking about long-term
damage here and I think it can be vast.

MPlayer is (much) more than just a codebase and I'm afraid you're not
taking this into proper consideration.  Respect and a positive attitude
among ourselves is also a measure of the project's quality.  We've been
able to attract quite a bit of new blood in recent times.  I think this
is in no small part because we have managed to make MPlayer a more
welcoming place than it used to be.

Now we're about to flush all of this down the drain just to enforce
principles over an issue that could well have been solved differently..

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

I did wait a day, because I didn't have email over most of the weekend.
And it was good that I did.

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

I skimmed it briefly.  I review all changes in areas I maintain as well
as random things that grab my fancy for some reason.  This keeps me more
than occupied.

Diego

P.S.: Please consider fixing the '.' button on your keyboard ;)  No,
seriously, it's sometimes hard for me to follow your train of thought
when i'm not sure where sentences begin or end.