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

[Siarhei Siamashka]

On 30 January 2008, Balatoni Denes wrote:

> 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
> improvement, even though perhaps not as big an improvement as if the
> contribution was in a perfect condition.

There is at least one valid reason - poor quality code committed without
proper review may result in a security hole which would have a negative 
impact on the project...

> 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). As far as I can see, what I described would lead to faster
> feature additions to ffmpeg, 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).

I'm also in favour of incremental development. I'm almost completely time
starved for the last two years because of my current job (I'm trying to 
escape from this circle eventually). Anyway each of my free software
development iterations lasts only several hours at most and it is better to
have something useful and improved at the end of it to have some progress.

But flooding the mailing list with incomplete and "to be improved later"
patches would enormously increase pressure on the persons doing code review.
Also some irresponsible persons exist who just have a goal to have their code
committed (to fix their problems) and don't care if this code introduces
problems for the others and if someone would have to clean up the mess
afterwards.

A distributed version control system which is often discussed here may
probably help. The idea of having an easy and painless way for everyone 
to have his own branch looks attractive (though I have never seriously 
used distributed version control systems myself yet).

> 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 rights - 

Well, to be honest, I'm only replying to your post as I was implicitly
mentioned in it. I don't really care much if my patches get accepted in
ffmpeg SVN or not. After all, nobody can forbid me to use them myself :) 
Quite the opposite, I feel somewhat sorry because I get a free review, 
some good and useful advices, but ffmpeg does not get any immediate benefit.

A proper community of ARM developers just does not exists here, that's a part
of the problem. When submitting any patch, I can't be sure if the problem will
be even noticed soon enough if I accidently break something. This makes me
feel uneasy and forces to doublecheck everything, wasting extra time. This all
is quite stressful, it is a lot easier and better for one's peace of mind not
to submit patches :) My primary motivation to keep posting here from time to
time is the hope to raise some interest in the development for ARM eventually.

PS. Regarding ARM IDCT optimizations, we just got some technical disagreement
regarding alignment issues which is blocking everything. Not that it is not
solvable, I just don't feel like having long discussions.

> I must note however, that IMO it's good that Mans' code was 
> made available early in SVN) or even my sparc idct optimizations - which
> eventually were comitted, but none of the others I have mentioned have been
> up to now (for quite some time).

Mans is available here to fix his code if any problems arise. This makes him
preferable over some abstract random guy without commit access who may submit
a (broken) patch and run away :)