[FFmpeg-devel] Donations and what happens with them

[Michael Niedermayer]

On Sat, Jan 29, 2011 at 11:45:11PM +0100, Herv? W. 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.

Dont put words in my mouth

Iam chatting with ben about a compromis solution, but he has no time today.

here above i just meant the current situation i didnt mean
that is how i would like it to stay. But its possible it will stay that way
if the compromise fails.

I prefer a single merged repo but iam starting to like the split repo free
of the bullying about forgetting a space here, a uneeded #include there a
comment on #endif and all that

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/bcad40b0/attachment.pgp>