[FFmpeg-devel] Merge "contest"

[Michael Niedermayer]

On Mon, Feb 27, 2012 at 08:00:28AM +0100, Reimar Döffinger wrote:
> 
> 
> On 27 Feb 2012, at 07:48, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > On 27 Feb 2012, at 05:24, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> Iam replying here instead of todays snow docs flame as its quite a
> >> different topic and not so much flame id say
> >> 
> >> Reimar said there that:
> >>> If you have a specific funding proposal it would be easier for me to
> >>> say more about this.
> >>> But it is clear that mostly the foundation has been sponsoring big
> >>> projects, so I have no idea what other directors think about sponsoring
> >>> this kind of small but possibly long-term stuff.
> >> 
> >> 
> >> Now this is not so much a proposal than a little bit about the "small"
> >> above.
> >> 
> >> The daily merges are sometimes dead easy and sometimes they are not.
> >> The hard cases can be summarized by simply being buggy to begin with
> >> one way or another. A result that IMHO comes due to patches not being
> >> reviewed by people who know the code 
> >> But thats just idle talk, lets come to the point, as reimar mentioned
> >> the work being small i skiped the hard part of todays merge. I leave
> >> this to reimar or other interrested parties to merge. Ive added
> >> some terse quick comments to 2 of the commits in ()
> >> also i dont plan to merge these tomorrow or later, its really
> >> you (plural) or they will be missing.
> > 
> > Then they will probably be missing. I am sorry if I offended you by the word-choice.
> > I had tried to clarify it by adding the word "long-term".
> > Then point is that merging a single commit is a really small thing in comparison to e.g. writing a WMA lossless decoder.
> > Together it is a lot, but that would be a rather non-specific task.
> > I just have no experience with what the general opinion on such things is, none of the previously suggested tasks were really of that type.
> 
> Sorry for sending the reply to the wrong place.

> I'll probably have a bit of a look because I'm actually curious about those changes.

please do


> But I don't have much time to invest.

> If your intent is to prove something to me I don't think there is a point, I am at least somewhat aware of the effort, even though I expressed myself badly.

someone else on IRC also expressed himself badly, its not really your
mail that triggered me to write this ...
Part of the idea behind it was also to involve more people in the
merging effort, and there was also my secret plan that if people from
both sides conciously realize how much time the merging and picking,
double testing and bugfixing, etc. costs that maybe more people would
push stronger toward a more permanent solution of the split up project.

that said, technically theres no problem with continuing the daily
merges, the average amount of time spend on it is not close to being
a problem. But its changes like in this thread that eat time. Things
that arent completly correct, dont pass fate once conflicts are
resolved and that need manual bugfixing as a result.

Combine this with the author of these changes not reading my mail or
at least not reacting to any in the last 6+ months. And thats where
things get annoying.


> What would you want the foundation to do? What specific would you
> propose, e.g. who should get how much money for doing what exactly?

I think we should work toward a real solution of the fork situation
but if that fails i surely would not mind any funding for the work i
do. How much or how little is up for discussion. That said iam not
sure the foundation is the right group to fund that. My mail really
was not supposed to propose financial things here ...

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120227/bdbd645c/attachment.asc>