[FFmpeg-devel] [VOTE] FFmpeg leader

[Baptiste Coudurier]

On 10/2/10 6:46 PM, Felipe Contreras wrote:
> On Sun, Oct 3, 2010 at 2:21 AM, Baptiste Coudurier 
> <baptiste.coudurier at gmail.com> wrote:
>> On 10/2/10 3:52 PM, Felipe Contreras wrote:
>>> On Sun, Oct 3, 2010 at 1:05 AM, Baptiste Coudurier 
>>> <baptiste.coudurier at gmail.com> wrote:
>>>> On 10/2/10 2:43 PM, Felipe Contreras wrote:
>>>>> On Sat, Oct 2, 2010 at 11:25 PM, Baptiste Coudurier 
>>>>> <baptiste.coudurier at gmail.com> wrote:
>>>>>> I believe you are confusing "maintainers" and
>>>>>> "contributors" here.
>>>>> 
>>>>> How exactly?
>>>> 
>>>> Maintainers of the kernel are paid.
>>> 
>>> Some are, most are not: 
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS
>>
>>
>>> 
>> You have to be reasonable and compare what is comparable.
>> Of course some drivers are maintained by people for fun. How active
>> is the development on all these drivers ?
> 
> You are arguing for the sake of arguing
> 

And you are not ?

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

>>> We all are doing it on our free time. But fine, if you think 
>>> contributors by definition should receive more pain, then that
>>> alone answers why git has more contributors than FFmpeg.
>> 
>> You said that sending patches was great. Why are you now calling
>> it "pain" ? Or do you implicitly agree with me ?
> 
> Sending patches is great... if the project has a good culture of 
> reviewing patches. You are the one that is saying sending patches is 
> painful, so I assume there's something wrong with the culture, and
> my guess based on the comments from others is that that the problem
> is bike-shedding.

So, following your reasoning, we are actually giving more great time to
contributors than maintainers ? This is perfect.

Besides, why would there be something wrong about the culture because
_I_ don't like sending patches ?
The point is, maintainers are really welcome to send patches if they
_want_ to, if they don't want to and it's on the code they maintain,
they are _forced_ to. People can _always_ review on -cvslog and comments
will always be addressed.
This is better for maintainers, and IMHO given the situation of FFmpeg,
it is better for the project.

>> Can you please open your eyes, and realize that the adoption and
>> usage of git cannot be compared to FFmpeg ?
> 
> In fact I think more people use FFmeg than git. 
> http://qa.debian.org/popcon.php?package=ffmpeg 
> http://qa.debian.org/popcon.php?package=git

Well, I don't think using debian users is accurate.
Furthermore, git the program is installed as much as ffmpeg the program.
And git will be shipped along Xcode 4.0

libavcodec-dev ? Not that many.

These stats are weird anyway, how come libavformat52 is more installed
than libavcodec52 since the former depends on the latter, something is
wrong here.

google trends:
http://www.google.com/trends?q=git%2C+ffmpeg

See the huge difference ?

> I was about to generate numbers about how many patches come from 
> non-maintainers in FFmpeg compared to VLC, or whatever project you 
> think could be compared to, but since you are using SVN it would be 
> tricky to find the real authors.
> 
>> Every developer must follow ffmpeg-cvslog. That's a rule.
> 
> Are you talking about contributors, or maintainers? You can't decide 
> what contributors do.

I'm talking about maintainers. Maintainer = maintain some part of the
code, developer = have svn write access, contributor = send patch.

>>> And I disagree that they have the same level of quality.
>> 
>> What quality are you talking about. I'm talking about code
>> quality, assuming all the mistakes are fixed, and they are.
> 
> Code quality implies more than bugs, e.g. readability, consistency, 
> maintainability.

Definitely agree with that. But let's get back to the point.
My point is that having 10 commits or 1 lead to the same code quality.

You want to remove these commits because showing the mistakes makes it
non-perfect.

>>> That's like saying that if 10 commits that appear as one, instead
>>> of logically independent ones, the same level of quality is
>>> achieved.
>> 
>> That's what you seemed to imply by hiding "mistakes".
> 
> *logically independent*.

No it's not, let me quote you, since you removed the interesting part:
"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. Sure, nobody is perfect, but if you have a process
that gives better quality, why go for the less than ideal one?"

IMHO this clearly says that you want to hide mistakes.

>>> Perhaps so, if they are the exactly same commits, but when you
>>> have commits logically independent, it's easier to understand
>>> them and spot certain issues that would be otherwise very
>>> difficult.
>>> 
>>> Similarly, when you squash the original patch and the further
>>> fixes, you realize somethings on the original patch that seemed
>>> correct in the original version, don't make sense any more.
>> 
>> That's why you don't squash them. Because "fix for the fix" happens
>> more than you believe.
> 
> It happens less if you send the patch for review.

If it is about code that I maintain, I'm not sure at all.

>> I myself miss some problems with some patches, and I fix them
>> afterward when I realize it. Should I rebase and modify the
>> original commit ? I really don't think so.
> 
> No, ideally you should have sensed that there's something that might 
> go wrong and send the patch for review. Then the version that's 
> actually committed will appear as a single "perfect" one.

Hehe "perfect", you are dreaming in color my friend :)
And it's even worse in the multimedia field in my experience.
I really don't know where you get that idea that you can have perfect
code, perfect history, perfect commit logs.

>>> Plus, they are easier to bisect, and understand when looking
>>> back through history.
>> 
>> Of course it is better, that's why it's better to have all the 10 
>> commits instead of only the merged one that hides all the
>> mistakes. Are you implicitly agreeing with me once again ?
> 
> You are confused. The 10 commits I talked about where *logically 
> independent*. Let's say there are 3.
> 
> 1. Cleanup 2. Add a check 3. Do some stuff
> 
> It turns out the check breaks the build on some platforms, and 
> somebody is already working on a better version of the stuff you
> want to do. So the history ends up like:
> 
> 1. Cleanup 2. Add a check 3. Do some stuff 5. Unrelated change 5. Fix
> the build 6. Fix the previous stuff but do it more properly now

6 fix the build 7 fix the previous stuff

and 5 is a huge mistake, the rule is tree must always compile before commit.

> If you had send the 3 patches for review, 2. would be 2. + 5. and 3. 
> would be 6., they would remain logically independent, easy to read 
> from git log -p, and if you bisect in any of those nothing would 
> break. If you end up with the 5 fix-after-commit version the bisect 
> would be broken at some points, and it would be more difficult to 
> understand what happened, specially if there are other commits
> between 3. and 5
>
> I'm not saying all those patches should be merged as 1, I'm saying 
> there should be 3, as that's the logical division, not 5.

First, we already break the commits in separate changes, we also go as
far as not mixing cosmetics with functional changes.

And sorry I want both 3 and 7, I want somebody that looks at history
know why the previous approach _did not work_, before he tries it again,
and you know what I already happened to me on the code _I_ maintain.

I believe it is better for everybody.

Your theory assumes that everybody is knowledgeable about every bit of
the code, which is _definitely not_ the case.
I personally know shit about AVI or WMV, I cannot review the patches.
Who understands WMV better than Michael who is the maintainer ?
Only a few people can maintain and review MKV as well, the same goes for
MXF IMHO.

> Anyway, I was assuming you were using (you can use it on top of
> SVN), but it looks not everybody is. Not using git usually implies
> that sending, reviewing, and merging patches is more difficult than
> it should. It seems you either won't accept that sending patches is
> ok, or you need to be using the appropriate tools. Either way, I
> don't think I can argue any more until you move git.

I actually maintain my branches using git. I agree that using git would
be a lot easier, but that won't change my mind about the maintainer
ability to commit without sending patches if he feels like it.

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

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