[FFmpeg-devel] [RFC] Bug Bounty
Sat Jan 30 03:36:08 CET 2010
On Sat, Jan 30, 2010 at 12:34:45AM +0000, Carl Eugen Hoyos wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> > > encourages devs to create bugs and or not fix them until they are 24
> > > months old.
> > The 4500USD payments for SOC dont seem to draw people away from
> > submitting patches for free.
> > You suggest the 40Euro would have a stronger effect?
> While I wanted to write something similar as compn, I believe you have a point
> More important imo:
> Do you distinguish between bugs and feature requests in this proposal?
The proposal was just about bugs, we could extend it to includ feature
requests, we could also try it first like it is and decide later if we
want to extend it to include feature requests. ive no real oppinon here
also to clarify what i counted in my statistic, its simply all open and new
bugs, substatus was ignored.
> I ask
> because I originally set many actual feature requests that were opened as bugs
> to "reproduced" and only lately started to change the type appropriately.
> There are many older bug reports that are open/open (or even new/new) that were
> clearly reproduced by developers (as one can see reading the posts concerning
> the issue). I typically refrained from adding another message "Fixing Status".
> Am I correct that you think it is not necessary that the issue was ever
> officially reproduced, but that a patch was committed in the end and the issue
> closed (which proofs that there was an issue and that the patch fixed it).
yes but for example i would disqualify things like:
someone submits a bug about a decoding problem of a file he cannot
share and a year later submits a fix.
Or if someone submits an invalid bug report and 2 years later provides
the missing gdb output & sample file and a day later a patch.
> (Some issues are new or open because I can't say if they are valid or not.)
> Apart from that, I agree with Vitor that we should raise the bounties from your
> proposal. Additionally, we should already consider to set higher bounties for
> some issues (H264 timestamps, VC1 interlaced if not chosen again) if some
> developers agree that they are important.
Iam not sure how much luck we would have with things like
H264 timestamps and VC1 interlaced
these are complex and require either someone with preexisting knowledge,
lots of time or lots of skill (and preferably all 3).
In that sense iam not sure if anyone would
pick it if we where to put a bounty of 2000 euros on these, of course at
some amount and if its posted to some place where many good developers are
hanging out some expert C coder would pick it up and do it.
In that sense iam not against putting bounties around 1-2k on hard and "wanted
by many people" tasks.
But it must be clear here that this likely will not work out at that price
tag, and we will have to raise the amount. My idea here would be to by hand
look over these high value tasks and consider to raise the bounty every few
months until someone does pick it up and does it or until we feel its too
expensive for us.
Also we first need to have money, several people already decided to donate
but part of this is google mentor money that google pays with years delay
aka which is not going to be available to us soon ...
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel