[FFmpeg-devel] [RFC] About committership

Janne Grunau janne-ffmpeg
Wed Feb 2 21:53:49 CET 2011

On Wed, Feb 02, 2011 at 08:49:14PM +0100, Stefano Sabatini wrote:
> On date Wednesday 2011-02-02 12:33:13 +0100, Luca Barbato encoded:
> > On 02/02/2011 12:10 PM, Stefano Sabatini wrote:
> > > Having each developer a separate branch/repo doesn't help neither, as
> > > I believed our gsoc experience in the last 3+ years taught, indeed the
> > > main cost and the most difficult task is the integration of the branch
> > > in the official repo, rather than the development of the branch
> > > itself, which every kid with some git experience can indeed achieve.
> > 
> > Because we were using svn. Rebasing on svn is costly, on git is easy.
> Uhm I mentored two projects the last year, both students were using
> git and it was greatly helpful, but still both projects haven't been
> properly integrated, I know that this doesn't depend (only) on the
> tools used, what I want to say is that better tools don't magically
> deliver perfect solutions, and that some policy is required.
> Also merges are easier, but still they require some effort, I need to
> resolve conflicts by hand many times when I rebase my local branches
> against the remote origin.

The most annoying parts for rebase are usually library versions,
APICHANGES and Changelog, merging code works most of the time.

> > > Moving the focus of the developer from "getting the change integrated"
> > > to "developing in her own branch" is not helping if the objective is
> > > actually "getting the change integrated" in the main repo.
> > 
> > I'm of the opposite opinion
> > 
> > > Also having each user to "cherry-pick" the changes from N branches is
> > > not a good idea as well and will just multiplicate confusion and
> > > mistakes.
> > 
> > The ffmpeg.org and possibly other target repos are here for this
> > purpose, cf linux in this regard.
> My idea is simple: one "official repo", with a stable and well defined
> API/ABI which external developers can pick at any time and develop
> against, and many repos which get synched from time to time. That is I
> propose to apply to the main repo the same rules we applied to the
> main SVN trunk.

Whatr are the many repos? Private developer repos?

> API major bumps should be done possibly after "official" releases, to
> reduce the impact on distros and other users ("company" users tend to
> use official releases as well, especially when they don't know the
> special nature of FFmpeg in this regard).

Only when necessary. But bumping Major version is completely orthogonal
to the repo discussion.

> Then you can have many topic repos/branches, but yet you need to
> define a mechanism and a policy for the synching, e.g. related to

private repos can have the API/ABI they like, only the official repo is
supported. Every change to the official repo has to be reviewed.

> Suppose that I want to create a topic branch. At some point I have a
> bunch of changes, after some rebasing the changes are in shape, and
> the branch has been tested (how? I suppose FATE can be used with other
> branches but the main one, but how much would it costs in terms of
> configuration, bandwith, energy etc. etc. having N instances of FATE
> one for each topic branch?).

you can always make fate locally

> Who is going to review the patches when they are going to be
> merged, and who decide when and how to merge?

The developer decides when he sends the patches for review. They should
be reviewed by someone who's knowledgable about the topic of the

> Also what if the branch you want to merge doesn't comply with the
> rules for the main repo (e.g. in terms of formatting)?

Depends on the style and how large the patch. Either rejected or if the
style is the only issue and we have a motivated committer the committer
can clean it up.


More information about the ffmpeg-devel mailing list