[FFmpeg-devel] Donations and what happens with them

[Michael Niedermayer]

On Sun, Jan 30, 2011 at 01:11:45AM +0100, Stefano Sabatini wrote:
> 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.

so far manual conflicts needing resolution: 0


> 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.

yes, but let us first look into the compromise thing. if that fails we
can fight it out and see which repo is still alive in a year.


[...]

> 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.

iam mostly ignoring the new rules as a experiment, i doubt it will work out
but if it does great, if not i dont want to have my name on major amendments
of them and people pointing at me for their own incompetence in coming up
with good rules



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/20110130/c4e0b5ab/attachment.pgp>