[FFmpeg-devel] [VOTE] FFmpeg leader
Sat Oct 2 14:44:49 CEST 2010
On Sat, Oct 2, 2010 at 5:39 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sat, Oct 02, 2010 at 03:29:16PM +0300, Felipe Contreras wrote:
>> On Sat, Oct 2, 2010 at 12:49 PM, Baptiste Coudurier
>> <baptiste.coudurier at gmail.com> wrote:
>> >> I believe we agree that maintainers are free to apply patches on the
>> >> files they maintain, but in general there should be some exceptions to
>> >> this rule. Such exceptions may arise when:
>> >> * the change affects the policy or the style of the project
>> >> * the change is no trivial, so it may benefit from peer-review
>> >> * the change affects other code not maintained by the committer *or*
>> >> ? the public interface
>> > 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'.
>> 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:
>> 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
>> It should be fun for you to receive constructive criticism from your
>> peers, which in the case of FFmpeg, constitutes very highly skilled
>> individuals, perhaps the best in the world in multimedia, I don't see
>> how you would find it more exciting to pass the opportunity of getting
>> such valuable feedback.
> then you live in a cave and havnt looked out in the last years
> what is reality is that people fork ffmpeg right and left because they
> are increasingly unwilling to put up with the bikeshed reviews
So in other words:
a) You are going to ignore the review process because you don't like it.
b) You are going to flame other people for ignoring the review process.
Stop the fucking double standards. If the review process sucks, then
fix it or dump it -- don't break it yourself while simultaneously
flaming others for doing the same.
You flamed basically every single other x86 asm maintainer just a few
days ago for doing something you didn't like -- and then proceeded to
commit a ton of code with no review. This is completely unreasonable.
Stop this hypocrisy.
More information about the ffmpeg-devel