[FFmpeg-devel] Donations and what happens with them

[Stefano Sabatini]

On date Saturday 2011-01-29 23:45:11 +0100, Herv? W. encoded:
> On 29 January 2011 19:29, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Jan 29, 2011 at 06:36:00PM +0100, Herv? W. wrote:
> >> On 29 January 2011 17:43, Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> >> > 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.
> >
> > nah, you misunderstood, iam speaking of specific formating and
> > "ohh my eyes a bleeding" requirements not stability.
> >
> > broken code is NOT welcome in the videolan repo.
> > but if someone has an issue with the existing (quite strict) whitespace
> > formating rules, but the code is otherwise fine, its welcome in videolan
> > also just because some code has mplayer ancestry does not exclude it from
> > consideration nor if it comes from anywhere else. For me the actual code
> > matters not how its formatted or where its from.
> > And i will pull all imrpovments mans does so its not that his tree would
> > have any better formated code, just less code.
> 
> So basically, you'd like it to remain the way it is now.
> V?ctor, Stefano, Reimar, Jason, Nicolas and others, do you agree with
> that? should I shut up and let things develop however? Personally, I
> think the way it is now is messed up with the back and forth pulling
> of changes between the two repos.

I have the same impression that this is going to be a pointless
duplication of effort, from what I can understand from the way git
branch&merge workflow, it works best when you have an "official" repo
and a topic branch which is synched from time to time. I have some
doubt that as more and more changes are done to both repos, it will be
still easy to keep them synched without more and more manual
resolution of conflicts. If we want to go through this path at least
some plan should be done for keeping the two repos API/ABI compatible.
Please correct me if I'm wrong.

Also in this case who reviews for what? If I post a patch, do I have
to say "this patch is for the videolan/ffmpeg repo"? That's going to
create an unnatural division of the work of the group, I don't think
that we can neither afford such work splitting neither that this is a
particularly good idea in principle.
What is going to be for the new contributors? Ehi, did you posted the
patch for the git.videolan.org or for the git.ffmpeg.org or for the
git.foobar.org repo, each one with a different set of rules and
maintainers and reviewers?

A natural evolution looks this: ffmpeg at videolan -> libmpcodecs branch,
synched from time to time with the ffmpeg at ffmpeg repo. This naturally
depends if Michael and the others want to contribute directly to the
"Mans" repo.

I believe that we should consider this like a sort of "transitional"
phase, where many of the rules after the "reorganization" need to be
elaborated and defined in a more clear way, provided that we accept
for granted that a new form of "organization" is wanted and/or
required (at least for the first point I believe there is reasonable
evidence).

That's why I would like to know which are the practical conditions
that both parts would find acceptable for continuing to work togheter
in the same repo (with occasional branching&merging from
personal/topic branches/repos).

Changing root admins for the FFmpeg server has been proposed as one
condition, having Michael renounce to his "leadership" status in favor
of some form of "shared leadership" (yet still being maintainer for
the FFmpeg parts which are under his maintainership) seems basically
what the other "party" wants.

As for the other "new" rules (committership vs. maintainership, etc.),
the past discussion showed some flaws and many obscure parts which
needs to be defined, so there is a wide margin for discussion and
improvement.
-- 
FFmpeg = Furious and Frenzy Mastering Powerful Epic Gargoyle