[Ffmpeg-devel] [RFC] ffmpeg-windows mailinglist?

[Augie Fackler]

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:
>>>>> <snip>
>>>>> FWIW, I have seen several patches of interest to me go completely
>>>>> ignored on this list.
>>>>
>>>> Examples?
>>>
>>> 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  
overall noise

>
> 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  
> and
> 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
>>>> that
>>>> are unlikely to be accepted.  Also some requests for changes in  
>>>> those
>>>> patches were never fulfilled, I reviewed some of the build system
>>>> myself...
>>>
>>> yes, macintel and windows patch authors have the strong tendency to
>>> ignore
>>> 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  
>>> comments
>>> 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/
>> trunk/ffmpeg-svn-mactel.patch>:
>> -        ".balign 16                     \n\t"
>> +        BALIGN_16
>> and
>> +#if defined(__APPLE__)
>> +#  define BALIGN_8  ".align 3 \n\t"
>> +#  define BALIGN_16 ".align 4 \n\t"
>> +#else
>> +#  define BALIGN_8  ".balign 8 \n\t"
>> +#  define BALIGN_16 ".balign 16 \n\t"
>> +#endif
>>
>> 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.

Thanks,
Augie

>
> Diego
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel