[FFmpeg-devel] Donations and what happens with them

[Hervé W.]

On 29 January 2011 17:43, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Jan 28, 2011 at 12:20:09AM +0100, Herv? W. wrote:
>> On 27 January 2011 22:31, compn <tempn at twmi.rr.com> wrote:
>> > so you guys want michael to not be leader.
>> > and michael wants mans and diego to not be root if he is not leader.
>> >
>> > is that it basically? thats the entire list of demands on both sides ?
>> > doesnt seem so bad.
>>
>> That's what I thought after reading these latest emails too. (Though
>> Michael did not mention Diego when he said "and i refuse to continue
>> to work under mans as root if iam not leader." )
>>
>> Here are some ideas to maybe move forward:
>>
>> People
>> ------
> [...]
>> M?ns steps down as _root_.
>
> dont skip diego please

Is this an absolute necessity? Atilla seems to be fed up with it and I
think it would be good to have some continuity.

>> Trees
>> -----
>> (I hate to bring it up, but ... ) The best compromise concerning
>> mpcodecs I've seen was put it on a branch and have some sort of
>> porting marathon. I think lu_zero suggested it.
>> Sync the two git trees on git.ffmpeg.org and git.videolan.org.
>
> about libmpcodecs -> libavfilter porting (and making it LGPL), i have
> found someone who might be willing to do it when funded by the foundation

Great! Two plans on how to deal with mpcodecs! With some luck at least
one will work.

>> Procedure
>> ---------
>> Some people seem to be upset that they can't commit (in the svn sense
>> of the word) to the git.ffmpeg repo even though they are (file)
>> maintainers. So that needs to be resolved. In the Announcement thread
>> it was stated more committers (svn definition) could be added later.
>> Would a solution be: grant file maintainers write access to the repos
>> again, but maintain the rule (from the Announcement) that all changes
>> must be reviewed by another developer who is deemed knowledgeable on
>> the topic. (Review on the ffmpeg-devel mailinglist, so that it's in
>> the mailinglist archive.)
>
> the idea is good but why would a review step be needed? we are a bit short of
> "knowledgeable on the topic" people. Theres a high risk this leads to fake
> reviews where someone just says ok because someone has to say ok even though
> noone really understands the code

I know qualified reviewers are in short supply, but I think this is to
allow development in which there isn't one single leader to make the
hard decisions.

If no qualified reviewer is available, I guess review would consist
more of asking the contributor questions ("Why did you make this
decision?"). Either way, it should catch more stupid typo's and might
even educate the reviewer.
As long as the reviewer is honest about his/her skill level it should
work okay and would prevent commits that have _only_ been checked by
the person who wrote it.

> Also file maintainers can commit to videolan and mans can then review,change
> and pull as he sees fit. If you are lazy _this_ really is the way to go :)

I don't think a stable repo on videolan and a more-stable repo on
ffmpeg is wise. I think either 1 repo, or 2 repos that are exact
mirrors of eachother would be better.

-V