[FFmpeg-devel] [VOTE] FFmpeg leader

[Felipe Contreras]

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, this has nothing to do with
my original point, but I answered you anyway, I probably shouldn't
have.

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

> 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

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.

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

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

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

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

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

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.

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.

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?

-- 
Felipe Contreras