[FFmpeg-devel] Donations and what happens with them

[Stefano Sabatini]

On date Friday 2011-01-28 00:20:09 +0100, Herv? W. encoded:
> 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
> ------
> Michael steps down as FFmpeg _leader_.
> M?ns steps down as _root_.
> 
> 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.
> 
> 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.)

Other technical reasons.

Having committ right simplifies the commit of uncontroversial changes
(e.g. typos, trivial fixes), with git is a simple matter of git commit
-p and some rebasing, having to pass through the send-email+review
chain looks like unnecessary burden.

Also sometimes patches have complex dependencies which are not easy to
spot but for the contributor (which can see the list of changes in her
local branch). I tend to send my patches as soon as possible (well I
admit this is sometimes *bad*), sometimes before a "dependency" patch
is already applied, and sometimes the order of the patches changes
according to new changes which become evident during the review
process. Moving the burden of keeping track of the dependencies
between patches from the developer to the committers is not a good
idea imo.

On the other hand I really like the queuing mechanism adopted (if I
understand it correctly queued patches are sent to FATE and are
committed only if they pass regression tests).

I see that the current system (committer vs. developer) is adopted for
forcing the review process with no exceptions and thus avoiding
post-commit flames due to not-reviewed controversial changes, I wonder
if it would be a good idea to simply impose the same restrictions via
policy rather than via the commit mechanism itself.
-- 
FFmpeg = Forgiving & Fanciful Meaningless Peaceless Excellent Game