[FFmpeg-devel] [VOTE] FFmpeg leader
Sun Oct 3 00:05:14 CEST 2010
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:
>> On 10/2/10 5:29 AM, Felipe Contreras wrote:
>>> On Sat, Oct 2, 2010 at 12:49 PM, Baptiste Coudurier
>>> <baptiste.coudurier at gmail.com> wrote:
>>>> Please let's be reasonable. We are all here for fun (for now at
>>>> least). Given the man power available, given the work, we
>>>> cannot reasonably enforce strict rules like you would do in
>>>> projects like the kernel, where day jobs and money are
>>>> involved, let's face it.
>>> This rule, or guideline rather, ensures code quality, and
>>> fairness. I don't see how sending patches to the mailing list
>>> first would be any less fun... it tells the community "I care
>>> what you think, and I care about the quality of this code'.
>> Well, it seems you are part of this "community", did you ever
>> review a patch on ffmpeg-devel that you didn't send ?
> I don't consider myself part of this community (yet), I just wanted
> to provide feedback as to what other projects do. I do read patches,
> and perhaps I've made a comment or two, but I don't think I know
> enough of the culture here.
>>> Also, you are assuming (for some strange reason) that everybody
>>> that works in the kernel is doing so because they are getting
>>> paid; I think you are completely wrong. People contribute to
>>> linux mainly because it's fun, and challenging, and it matters.
>>> Some people coincidentally do get paid, but they anyway keep
>>> contributing on their own free time, abiding by the same rules.
>>> And the majority of people are not paid in any way:
>> I believe you are confusing "maintainers" and "contributors" here.
> How exactly?
Maintainers of the kernel are paid.
> 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.
> 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.
> IMO contributing patches should be fun for everyone, regardless of
> their rank.
I totally agree with that.
>>> And what about projects like git? Or vlc? The developers surely
>>> don't get paid for contributing, and still send each and every
>>> patch (or mostly).
>> I didn't say developers on git were paid, I don't know about that.
>> Like I already said git is a major project, and cannot be compared
>> to FFmpeg in man power, number of active contributors, nor
> But how do you think they managed to gather so many contributors?
I believe because git is a more "mainstream" project, used by more people.
> Take a look at these numbers:
> In git everybody is equal, that's why it's so easy for new people to
> get involved, do a bunch of changes for one release, and then
> disappear, and in every release a big amount of changes is
> contributed this way.
> I think the problem with the maintainer vs contributor mentality is
> that once you become a maintainer, you have trouble making sure that
> things are smooth for the rest. If everybody is bound by the same
> rules, then everybody is vested in the same development process.
> If you are saying that the development process for non-maintainers
> is too burdensome for you, then perhaps it should improve. It's not
> fair that the rest of us has to go through all the plain to become
> maintainers before actually start having fun.
We'll have to agree to disagree here.
I'm gonna repeat what I said above:
A maintainer should be trusted, and because of this you cannot in
"fairness" consider a maintainer and a simple "contributor" the same way.
I believe FFmpeg works as a meritocracy.
>>> By the time it hits the SCM it's too late, it has tainted the
>>> history... forever. Why would you want to do that if you already
>>> have an alternative that works in so many other projects?
>> May I ask you why you think it "taints" the history ? I don't mind
>> having mistakes in the commit logs, because it shows honesty,
>> nobody is perfect.
> 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.
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel