[FFmpeg-devel] [RFC] replace some static with asm_visibility?or?so

[Michael Niedermayer]

On Wed, Jan 30, 2008 at 10:21:28PM +0100, Balatoni Denes wrote:
> Hi!
> 
> Thanks Michael, for addressing my points in detail.
> 
> Wednesday 30 January 2008 13:13-kor Michael Niedermayer ezt ?rta:
> > There are 2 problems ...
> > 1. If he knew the amount of time at the begin chances are he wouldnt even
> >    start fixing anything.
> 
> This does lead to another (so far implicit) point. I don't see why a 
> contribution that is an independent module (not touching any other code 
> significantly), and is an improvement to ffmpeg is only acceptable when it 
> is "perfect". Imho such contributions could be comitted to svn, as they don't 
> lead to any regression - at least not that I can see now - but an 

Some problems are:
Bigger object files, more memory needed, more source.
Also people do copy and paste code and use it as example to base their
contributions on. And the interrest in cleaning up code to get it into svn
is generally much bigger than cleaning up code which already is in svn.
And then iam sure some will complain about being treated unfairly because
their code is not considered independant.
In the end accepting independent code if its a mess, would lead to far worse
overall code quality in ffmpeg.


> improvement, even though perhaps not as big an improvement as if the 
> contribution was in a perfect condition. I think just because such a patch 
> that I described above is comitted as is, that doesn't mean it shouldn't be 
> improved later - on the contrary it should by all means, although not 
> neccessarily by the original contributor (as he might not have time for 
> example). 

Nothing prevents interrested people from picking up patches and cleaning/
improving them. Theres no reason why this would be limited to the author.
Also if you look around, many patches do get improved by others before
commiting, roman commonly cleans up DV related patches before commit.
Also the attachment patch was worked on by aurel as well as the author.
The MMS patch as well has been worked on by at least 2 people.
If noone else does work on it that is a pretty good sign noone else would
have in svn either IMO.


> As far as I can see, what I described would lead to faster feature 
> additions to ffmpeg, 

yes, but this comes at a high price, that is quality and maintaince issues.


> happier contributors (they are more often rewarded, by 
> having their contribution comitted), and there are no disadvantages I see.
> I don't belive that only letting "perfect" contributions comitted would really 
> urge contributors fix their patch - they might jump through all the hoops 
> once, but maybe not any time later (i.e. they stop sending patches).

You did cleanup the IDCT code, iam certain you never would have after it
was in SVN. But hey proof me wrong, it is in SVN now and it still can be
improved :)


> 
> Patches that would fit my description would be for example  
> Ian Caulfield's MLP decoder, some of Christophe Gisquet's optimizations,

> Siarhei Siamashka's arm idct optimizations (this also shows a double 
> standard, because Mans - who has SVN commit rights - was free to commit 
> suboptimal code, that has never been accepted from anybody without SVN commit 

If you think someone commited suboptimal code, please reply to the commit,
preferably to ffmpeg-dev and describe what you think its suboptimal.


[...]
> > And if the author choose not to
> >    fix anything due to the amount of work, the review time would be
> >    wasted.
> 
> Yes, otherwise the author's time is wasted, by perfecting patches that are 
> never comitted.

This is not true, other people can pick up such a patch and do the remaining
work. And that is less work than if the author droped it immedeatly.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080130/2fe06f78/attachment.pgp>