[FFmpeg-devel] [RFC] replace some static with asm_visibility or so

[Ivan Kalvachev]

On Jan 29, 2008 4:26 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Jan 29, 2008 at 06:56:07AM +0200, Uoti Urpala wrote:
> [...]
> > > threats do as well. Had you no svn write access it would be a mere single
> > > reply with "doesnt work with gcc 2.95" and the issue would be closed.
> >
> > And development wouldn't progress either. You think gcc 2.95 support is
> > more important than the things I've done for MPlayer?
>
> Yes, thats what i think. I also think others could have done the same
> in the time they wasted in flames and extra work caused directly or
> indirectly by you.
>
>
> [...]
> > > Third, you repeatly said you act by your own rules and dont care about
> > > the policy if it differs from what you consider best.
> >
> > I don't care what is written in the policy document.
>
> Thats what i meant.
>
>
> > It's not written
> > with such detail that it could be reasonably applied to every case
> > without exceptions, nor is there a working system for deciding the
> > contents in case people disagree what they should be. It's not suitable
> > for deciding cases where there is genuine disagreement about how
> > development should be done. It also has obviously bad rules that nobody
> > else follows either ("you must leave incorrect indentation in the
> > code").
> >
> > Referring to "the policy" is just an invalid try to argue by appeal to
> > authority in cases where you think something should be done in a certain
> > way because that's how you did it before.
> >
> > >  Now one can argue
> > > if the policy is good or bad (i consider it quite good) but having a
> > > developer living and acting by his own rules causes serious problems.
> > > It partly works out as long as its just one person and he is rather inactive.
> >
> > How many developers are not "rather inactive" by your criteria?
>
> Most are rather inactive, and i had the feeling that the vote and especially
> the following things did worsen that further.
>
>
> >
> > > Where there two with such an attitide things would get really messy.
> >
> > That's what you claim, but that doesn't make it true. I don't insist
> > that everyone do things the way I do (so claiming that multiple people
> > with my attitude would necessarily cause conflicts would be false). Most
> > of the flaming has been triggered by people who do little development
> > themselves, and whose own minimal development almost certainly will not
> > be affected one way or another by how I work, but who still try to force
> > me to do it the way they want.
> >
> > Take for example the command.c creation which made you try to get my
> > account closed and which you've used as an example of what "bad" things
> > I've done. That didn't break functionality, worsen source quality or
> > prevent others from doing development. No, what upset you was that I was
> > not willing to do it the way you wanted. I have not flamed others who
> > have done similarly useful things, not even if they didn't do them the
> > way I considered best. If there were more people with my attitude (and
> > skills to actually do changes like that) MPlayer would just improve
> > faster.
>
> The command.c creation was a 221k change which was mostly cosmetics but
> contained significant functional changes as well. Completely unreviewable.
> Other developers had to split and redo the whole cleanly as you refused to.
> And you were unanimously asked to revert/clean it up it was not just me
> but pretty much all other active developers.

Not only that. The whole mess was developed for 2 days and in short
was creation of mpctx struct that holds all globals inside mplayer.c .
It was inspired by long standing goal to make libmplayer that could be
used as means for generic playback.
Unfortunately Uoti had no idea what he was doing. Most of the globals
we were talking are actually option parameters and he haven't touched
them. These globals are additionally interconnected with the playtree
functionality that allows tree-like playlists. It's not simple goal to
make clean implementation and not loose functionality.

Instead of cleanup the commit brought only mess, it needed inclusion
of various headers in unrelated parts of mplayer only to support the
mpctx struct members.  A majority of the changes were changing the way
variables are accessed. The initial commit didn't include the changes
required to make GTK gui and OSD Menu work.

The mess was never reverted. It soon would be one year after the
initial commit. All Uoti have done about it was to recommit it with
preserving the history. There's been Zero (0) development since.

There was never real discussion about the changes (I tried to start
one) and you already know how futile is to argue with Uoti.  He never
accepted the possibility other developers to tell him what should be
done and he never admitted doing something wrong.

Diego put his reputation at stake to save Uoti from the mess. I think
the time shows it was loosing bet.

Anyway, these are all MPlayer problems, they have nothing to do with
FFmpeg and the best course of action is just to ignore Uoti rants.


Here I saw concerns about FFmpeg leadership. I think that the the
facts speak clearly. FFmpeg at the moment is in peak form. The SoC may
be the cause, but Michael reviews are what sets higher coding
standards.

About the grammar. There is nothing worse than making your best
efforts to do something and then been ridiculed over the result.