[FFmpeg-devel] [VOTE] FFmpeg leader
Sun Oct 3 00:52:51 CEST 2010
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:
>> Should maintainers be allowed to "have fun" and contributors not?
> No at all. Life should be made easier for maintainers, especially if
> they do that for fun and in their free time.
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.
>> I think the definition of maintainer is different here than in the
>> kernel; there a maintainer can decide not to be a developer (only
>> review and merge patches); the two roles are separated, when a
>> maintainer decides to develop, he does so as any other developer and
>> submits patches for review.
> Well, I'm not a big fan of this double situation.
> A maintainer should be trusted, and because of this you cannot in "fairness"
> consider a maintainer and a simple "contributor" the same way.
And of course they are trusted, they have commit access, and they can
decide whether their patches merit review or not, but should not be
based on whether they are in a hurry or not, or it would be though. It
should be based on whether or not the community might have a say on
the patches or not, and if they are not making that decision
correctly, perhaps they shouldn't be trusted with maintainer status.
>> 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
>> If you go hunting a bug one year back you most certainly would not
>> like to see a commit split in two or three: a buggy one, a fix by
>> developer B, and then another one by developer C all on the same
>> code. Sure, that's "honest" but it's wasteful.
> Both gives the same level of quality wether mistakes are shown in log or
> not, since they are eventually fixed.
> If you hide these mistakes, nobody can learn from them except you and I
> sure know that by experience.
I think more people follow the ffmpeg-devel mailing list than the
commit log, so I don't see what could really be hidden by sending
And I disagree that they have the same level of quality. That's like
saying that if 10 commits that appear as one, instead of logically
independent ones, the same level of quality is achieved. 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.
Plus, they are easier to bisect, and understand when looking back
More information about the ffmpeg-devel