[FFmpeg-devel] [VOTE] FFmpeg leader
Sun Oct 3 01:21:41 CEST 2010
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"
>>> How exactly?
>> Maintainers of the kernel are paid.
> Some are, most are not:
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 ?
Point is, kernel's pyramid has more levels than FFmpeg and it is IMHO
appropriate to place the top of both pyramid at the same origin point.
>>> Should maintainers be allowed to "have fun" and contributors
>> 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.
You said that sending patches was great. Why are you now calling it
"pain" ? Or do you implicitly agree with me ?
Can you please open your eyes, and realize that the adoption and usage
of git cannot be compared to 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
Well, I believe too many errors could lead to being revoked. This never
happened AFAIK, and I believe this is because the trust circle works
Like Michael said in this threads, many of his patches are not even
reviewed. Does this mean that the "community" trust Michael ?
I do trust Michael, and I do trust every maintainer.
You seem to prefer the "community" trust, I prefer the maintainers' trust.
>>> 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?
>>> 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
Every developer must follow ffmpeg-cvslog. That's a rule.
> 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.
> 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".
> 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.
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.
> 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 ?
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel