[Ffmpeg-devel] [RFC] ffmpeg-windows mailinglist?
Wed Aug 2 13:53:20 CEST 2006
On Aug 2, 2006, at 5:38 AM, Diego Biurrun wrote:
> On Tue, Aug 01, 2006 at 09:09:21PM -0400, Augie Fackler wrote:
>> On Aug 1, 2006, at 5:34 PM, Michael Niedermayer wrote:
>>> On Tue, Aug 01, 2006 at 10:10:50PM +0200, Diego Biurrun wrote:
>>>> On Tue, Aug 01, 2006 at 02:16:31PM -0400, Augie Fackler wrote:
>>>>> On Aug 1, 2006, at 11:24 AM, Diego Biurrun wrote:
>>>>> FWIW, I have seen several patches of interest to me go completely
>>>>> ignored on this list.
>>> yeah iam curious too ...
>> The only examples I can find with thread view on the archives being
>> such a nightmare were two that I had special interest in, wherein a
>> couple of macosx-related configure changes were ignored until they
>> were posted a second time (after waiting 3 days for a response in
>> both cases).
> Do I understand right that you are complaining that some patch sat in
> the queue without getting a response for 3 days ?!?
Not precisely - your turnaround on most patches is 24 hours, so the
general assumption *I'd* make would be that a patch got lost in the
> May I remind you that reviewing is unpaid, unceremonious and - as this
> mail exchange proves - extremely underappreciated work. Look at
> how few
> people do it. I'd say the ratio of committers to reviewers is
> about 10
> to 1.
Relax. I've reviewed patches for another project, it's generally not
fun and not rewarding.
> The reviewing situation in FFmpeg is excellent IMNSHO. Just
> compare it
> with other projects of similar size. MPlayer gets tons of patches and
> unfortunately many end up ignored because the reviewers are swamped
> most developers are lazy about reviewing.
> I believe you have things backwards. Reviewers should not go out of
> their way to accomodate patch senders, it should be the other way
> around. Reviewer time is just that much more valuable...
When I have a patch that would deliver theoretically desirable
functionality, I am frequently tempted to just rewrite it myself, but
I lack time for that, so usually I'll make a brief description of why
the patch is rejected and include a general idea of what could be
done to fix that if so requested (when I asked how something should
be done here, I was told to "write a patch, submit it, and if it's
not what we want it'll be rejected.)
All of this is neither here nor there at this point, because I have
the description of why the patch below is not wanted, and it should
be fairly easily fixed.
>>>> The mactel situation is unfortunate because it may not be
>>>> possible to
>>>> support the currently available toolchain without intrusive hacks
>>>> are unlikely to be accepted. Also some requests for changes in
>>>> patches were never fulfilled, I reviewed some of the build system
>>> yes, macintel and windows patch authors have the strong tendency to
>>> our comments to their patches, and then they come back and whine
>>> that we
>>> didnt apply their patch, of course we cant as they ignore our
>>> the dr-ffmpeg patches are another such example
>> Usually the comments boil down to "this is ugly" or something similar
>> with no feedback on what could make the patch "pretty" enough to be
>> accepted. As an example, taken from <http://svn.cod3r.com/perian/
>> - ".balign 16 \n\t"
>> + BALIGN_16
>> +#if defined(__APPLE__)
>> +# define BALIGN_8 ".align 3 \n\t"
>> +# define BALIGN_16 ".align 4 \n\t"
>> +# define BALIGN_8 ".balign 8 \n\t"
>> +# define BALIGN_16 ".balign 16 \n\t"
>> Is this really so ugly as to be a scar upon the codebase? If not,
>> then what in the linked patch is truly so objectionable?
> I think Rich did a good job of explaining this.
> It's a great pity IMO that most people seem to be content with
> coming up
> with a hack that makes their machines work but seem unwilling to
> work on
> a more general solution ...
The more general solution was never previously explained in a way
that was clear to me. As it is now, I understand the problem with the
patch and should be able to put time into cleaning it up properly.
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel