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

Uoti Urpala uoti.urpala
Tue Jan 29 05:56:07 CET 2008


On Mon, 2008-01-28 at 19:23 +0100, Michael Niedermayer wrote:
> On Mon, Jan 28, 2008 at 07:48:32PM +0200, Uoti Urpala wrote:
> > I don't quite agree with that description, but rather than discuss that
> > again let me ask you this: do you think the result would have been
> > better if you had managed to get my account closed? Would MPlayer be in
> > a better state now?
> 
> yes
> 
> First, the fact that root ignored the result of the vote was very damaging
> to the image of mplayer.

What image?

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

And because I guess you're going to reply with something like "what if
everyone broke some part" I'll reply in advance that restricting the
usage of the basic language syntax to work around the brokenness of
obsolete compilers is quite different from not breaking some part of a
program. I wouldn't ask others to write all their C differently to work
around problems in my pet tools either.

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

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

> I dont need to remind you that you openly threatened that you would
> revert compilation fixes.

"compilation fixes" to code which worked perfectly fine, and which
"fixes" uglified the code and originally broke its functionality too.





More information about the ffmpeg-devel mailing list