[FFmpeg-devel] Donations and what happens with them

[Michael Niedermayer]

On Sat, Jan 29, 2011 at 06:09:56PM -0800, Jason Garrett-Glaser wrote:
> On Sat, Jan 29, 2011 at 2:45 PM, Herv? W. <H.O.W.aka.V+ffmpeg at gmail.com> wrote:
> > 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.
> 
> IMO a pulling war is very stupid.

IMO every war is stupid, thats why we are trying to find a compromise

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/f4071ab3/attachment.pgp>