[Ffmpeg-devel] Re: Using ffmpeg libs in an OSS project is a nightmare

[Tim Allen]

Burkhard Plaum wrote:
> So my question is the following: Would forking be possible
> without offending anyone? If there was another ffmpeg CVS
> repository, which is automakified, but otherwise closely

Tactical error - leave autoconf etc out of it. Fight your battles one at 
a time :-). It's irrelevant to what you want to achieve anyway.

> synced with the primary CVS, regular releases can be made
> from that. A smart shell script can sync the CVS almost
> automatically, even if the build systems are different. If
> some projects, which depend on ffmpeg, work together, the
> amount of labor stays reasonable. The ffmpeg people can point
> to these releases as "unsupported regular releases, using CVS
> is preferred". The only things we must make sure, are
> that ffmpeg developers aren't bothered with reports about bugs,
> they aren't responsible for, and that general bugfixes find their
> way back into the original ffmpeg.
> 
> Any opinions?

Ideally, if there was the labour available to make it happen, then 
whoever was managing the releases would make a stable branch in the cvs 
archive at particular times, and _maintain_ the stable branch. Ie apply 
urgent bugfixes, particularly security-related ones, to the stable 
branch, and redo stable releases from that branch. Any time cvs head has 
enough progress to show, a new branch would be made. You wouldn't need a 
new archive for this - as long as you can persuade Michael and others 
that you're serious about doing the work, I'm sure they'll let you do it 
in the main archive.

In the absence of someone prepared to do that, then there is IMHO 
limited value in formalising the releases. The idea that somehow 
blessing a particular cvs snapshot and uploading it to sourceforge some 
number of times a year is somehow valuable is hard to fathom. Sure, you 
get some degree of API stability, but you also get bugs and security 
problems and no clear way of fixing them.

In particular, badgering Michael to do the work of release management is 
a mistake. He's doing very well working the way he is - leave him alone 
and let him get on with it.

Tim

-- 
-----------------------------------------------
Tim Allen          tim at proximity.com.au
Proximity Pty Ltd  http://www.proximity.com.au/