[FFmpeg-devel] [MPlayer-legal] [VOTE] New root crew for mphq and new projectleader for FFmpeg

Michael Niedermayer michaelni
Sun Oct 3 18:46:37 CEST 2010

On Sun, Oct 03, 2010 at 05:06:42PM +0200, Luca Barbato wrote:
> On 10/03/2010 04:39 PM, Ivan Kalvachev wrote:
>> On 10/3/10, Michael Niedermayer<michaelni at gmx.at>  wrote:
>>> On Sun, Oct 03, 2010 at 03:22:54PM +0200, Luca Barbato wrote:
>>>> On 10/03/2010 03:00 PM, Michael Niedermayer wrote:
>>>>> yes, i agree.
>>>>> Having the admins at the same time be core developers of the projects
>>>>> they
>>>>> manage is a bit a conflict of interrest and not ideal.
>>>>> Like in the foundation treasurer, president and secretary should be
>>>>> seperate
>>>>> people and developers of the projects and the server admins too should be
>>>>> seperate that is ideally.
>>>> I think you are both overestimating the roles and I don't see where is
>>>> the conflict of interest.
>>> mans is a developer of ffmpeg, jason is a developer of ffmpeg they had a
>>> disagreement about something in ffmpeg and mans closed jasons account by
>>> using
>>> his root power.
>>> thats not theory but reality
>> r22914, on April 19 cvs-log.
>> I had replied in that thread and tried to notify Attila right away.
>> I'm still not sure if Mans really closed the account, as Jason
>> committed irrelevant change after 2 hours, but even
>> pretending/threatening to do so, is bad enough.
> Author: mru
> Date: Mon Apr 19 21:37:31 2010
> New Revision: 22914
> Log:
> Revert "Fix libx264 configure check to use pkg-config if available."
> This was done out of pure spite.  Commit rights revoked.
> Modified:
>    trunk/configure
> Change of files maintained by other on purpose to annoy who maintains  
> that. In other projects such commit might grant a suspension of 2  
> months, not for the commit but for the spite...

in mplayer of old times (aka before the whiners and bikesheds) a commit
against rules led to a warning and a second to account suspension

it worked well, noone did a 1-3rd person, asm doc removial, redundant stdlib.h
inclusion commit as they would have had to send patches after the 2nd violation

and few tried because they knew the consequences. But now and here such
hard consequences are kinda unpopular and it seems to work fine in most cases.
I think we arent yet at the point where we have to use such rules though.
and if it comes to it that is the decission of the community or the leader
not roots.

>>> mans said "I do not recognize you as a leader."
>>> so based on what would he mange the git write accounts of the ffmpeg
>>> project?
>> r25286 , that's still on the first page in cvs-log, I guess you've seen it.
> It is apparent that w/out that something would break if common.h isn't  
> there.

yes it would fail with not finding common.h

> Discussion on that, could be derailed somewhere else. I didn't
> check if there is optional code already in this situation. Usually I  
> prefer having the headers for the code used in a file present for 
> clarity.

maybe but past discussion IIRC said that common.h is an exception and the
headers included by it dont have to be redundantly included everywhere.
common.h is included unconditional by avutil.h which is included by everything

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20101003/904649b6/attachment.pgp>

More information about the ffmpeg-devel mailing list