[FFmpeg-devel] [RFC] replace some static with asm_visibility or so
Tue Jan 29 11:20:10 CET 2008
Michael Niedermayer wrote:
> On Tue, Jan 29, 2008 at 02:42:17AM +0100, Diego Biurrun wrote:
>> On Mon, Jan 28, 2008 at 03:18:36PM +0100, Michael Niedermayer wrote:
>>> On Mon, Jan 28, 2008 at 10:15:56AM +0100, Diego Biurrun wrote:
>>>> On Mon, Jan 28, 2008 at 04:31:07AM +0100, Michael Niedermayer wrote:
>>>>> On Mon, Jan 28, 2008 at 01:59:05AM +0000, M?ns Rullg?rd wrote:
>>>>>> Let's just get one thing straight: FFmpeg != you.
>>>>> I did not claim this, but ffmpeg is even less you. Still you threaten
>>>>> to make decissions about ffmpegs developers based on what you think
>>>>> is best or what you think is a consensus amongth the active developers.
>>>>> Why is it that you think that your oppinion about a consensus amongth
>>>>> the active developers is better than the ffmpeg maintainers oppionion
>>>>> about a consensus amongth the active developers?
>>>>> After all ive not acted against the oppinon of the majority ever
>>>>> still you repeatly emphasize that you wont listen to me.
>>>> That is not true, you act according to your own best judgement,
>>>> regardless of where the majority lies.
>>> I act according to the majority on the mailinglist normally, i guess you
>>> might be able to find exceptions but this isnt that common. And certainly
>>> never when it comes to organisatorial things like crating mailinglists,
>>> i might ignore a majority if its about code and sufficiently silly.
>> What is "the majority of the mailing list"? A majority of the
>> developers disagreed with you about spelling,
> And iam trying to spell correctly, so ive followed that request.
> You can claim iam not good enough, and you can also claim i dont
> reread what i write 5 times. But dont claim i dont try to spell
> correctly. That just is a unjustified attack.
>> a majority also has a
>> different attitude towards compiler warnings,
> Please start a vote on this, no iam serious
> if >50% of the developers are in favor of
> "lets remove as many warnings as possible as long as it doesnt slow down
> the code, makes it unreadable or bloated" then iam not against adding such
> a rule to the policy and following it
I completely vote FOR this rule.
I'd like this rule to include explicitly or implicitly the removing of
gcc warnings like "suggested parenthesis around blah blah" and yes I
know C standard defines priorities clearly, but it's just annoying and
makes me hard time catching which warnings are bad and which are ok.
This was just one example Im thinking about.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel