[FFmpeg-devel] [VOTE] FFmpeg leader

[Baptiste Coudurier]

On 10/3/10 5:47 AM, Felipe Contreras wrote:
> Hi,
> 
> I'm going to stop, but I want to answer some points that I think
> should not be left unanswered.
> 
> On Sun, Oct 3, 2010 at 5:39 AM, Baptiste Coudurier
> <baptiste.coudurier at gmail.com> wrote:
>> On 10/2/10 6:46 PM, Felipe Contreras wrote:
>>> this has nothing to do with my original point, but I answered you
>>> anyway, I probably shouldn't have.
>>
>> It has everything to do with your original point.
>> You refuse to understand how and why the kernel can sustain the strict
>> rules. I'm trying to explain to you, but this is getting hopeless.
> 
> I already explained why the differences are not relevant, but you are
> not willing to listen. 

I'm reading what you wrote and it didn't change my mind.
You are stubborn.

> How about buildroot? You are probably going to
> find another excuse to ditch their policy. So if you are not going to
> allow comparisons with other projects, 

I'm allowing comparisons to some other projects, some comparisons you do
are not valid IMHO.

> and you are not willing to try new things

That is not true at all, I already proposed new things, you are not
reading what I wrote.

> [...]
> 
>> You want to remove these commits because showing the mistakes makes it
>> non-perfect.
> 
> You clearly didn't follow my analogy at all.

Dude, again you removed the relevant quote:
>> Why do you want to see mistakes in 'git log'? We all undo, rebase
>> commits, amend, squash, etc. Nobody cares about being honest and
>> push all those mistakes.

Then later:
>> "Then the version that's actually committed will appear as a single
>> "perfect" one."

That's what you said.

>>> What would be interesting to see is how you propose to solve the
>>> issue you have at hand. You do agree that the fact that one of your
>>> most prolific and competent developers leaving the project is an
>>> issue, and that he is clearly not happy with the double standards you
>>> seem to like. Right?
>>
>> It is a huge issue and I'm very sad.
>> I already mentioned that sending patches for API changes should be
>> mandatory. I even proposed that a substantial group of people should
>> validate the change before it's applied. You missed that it seems.
> 
> Good, so we agree that maintainers should send more patches for
> review. 

I agree that patches must be sent for API changes, therefore,
maintainers are not forced to send patches for code they maintain,
except when the API changes.

> The only difference is that I think the bar should be even
> higher, but I guess that's not relevant... 

And I try to explain you, that FFmpeg cannot really afford to enforce
stricter rules IMHO. Michael also did try to explain to you.
You are stubborn, even though you don't understand the project.

> what is relevant is whether
> Mans thinks the bar is high enough, and Michael is reaching it.

Yes, what's important IMHO is that every developer and every maintainer
in FFmpeg think that rules and principles are adequate and that
everybody is comfortable coding and participating in the project.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org