[FFmpeg-devel] [VOTE] FFmpeg leader

Michael Niedermayer michaelni
Sat Oct 2 15:56:31 CEST 2010


On Sat, Oct 02, 2010 at 05:58:53AM -0700, Jason Garrett-Glaser wrote:
> On Sat, Oct 2, 2010 at 5:56 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Oct 02, 2010 at 05:44:49AM -0700, Jason Garrett-Glaser wrote:
> >> 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:
> >> >>
> >> >> http://lwn.net/Articles/222773/
> >> >>
> >> >> 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).
> >> >>
> >> >> It should be fun for you to receive constructive criticism from your
> >> >> peers, which in the case of FFmpeg, constitutes very highly skilled ? ? t
> >> >> 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.
> >
> > Ive repeated it many times.
> > I do not ignore the review process or rules. And if you think i do please
> > point me to where i have, dont just repeat vague accusations.
> 
> I just pointed to three examples.  You cast them away by saying that
> you discussed the vague general idea before making the commit.
> Really?  Really?  That's all we need to do?

You continue to apply your own rules to ffmpeg instead of ffmpegs rules.
In ffmpeg the maintainer of code can commit without patches if he belives the
change to be non controversal. Without this rule developers will leave,
neither you, nor alex nor mans accepted review of their patches in the past
Its very odd you 3 now push to rules neither of you 3 is likely to accept
themselfs. Iam starting to wonder if its true what people have told me
that you want to destroy ffmpeg and make x264 replace it.
Trying to manipulate the ffmpeg policy so that everything comes to a halt
would be in line of that agenda

not to mention neither are patches for x264 publically posted for review
before commit so this is not even what is done in x264


> Whatever happened to
> posting patches and waiting for comments?  If anyone else did it, you
> would be all over them.

i let alex do it, i let you do it, i waited a long time while mans was doing
it over and over again.

All that said, i will from now on post patches that change external api
for code i maintain so as to avoid more of this.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101002/92fbf576/attachment.pgp>



More information about the ffmpeg-devel mailing list