[Ffmpeg-devel] Re: Advocating periodic releases

[Ulrich von Zadow]

Dana Hudes wrote:
> Tim Allen wrote:
>> Dana Hudes wrote:
>>> I am willing to give a go at project managing ffmpeg and doing
>>> releases. Somewhere along the way, I hope to also be able to make
>>> Solaris SPARC (sorry, I don't have any x86 Solaris systems) packages
>>> available. Part of the release thing is not only making sure that the
>>> thing builds and passes its regression tests but I'd really
>>> appreciate help on the QA side in assessing the adequacy of the
>>> tests. I can, I think, get some automated code-coverage metrics
>>> measuring tools going (if this were Perl, I'd know exactly where to
>>> go for them but its been a while since I did such on C code).
>>
>> Excellent. I hope you have thick skin, because while the contributors
>> to this project may not have decided to spend their time on release
>> management, you can be sure they have firm ideas on the way it should
>> be done properly and will let you know if you don't meet their
>> expectations :-).
> I have a fairly extensive background in commercial software and software
> engineering. I know what needs to be done. The trick is to balance
> between defect repair and new features. People much prefer to write new
> stuff. If they have to touch old stuff they like to rewrite it.
>>
>>
>>> I think we need a separate discussion list for the release / test
>>> issues so that interested parties are not flooded with discussions of
>>> patches. I would ask that any developer contributing actual code
>>> participate in the release discussion somewhat.
>>>
>>> As for the vehicle for all this, sourceforge would seem the right place.
>>
>> That choice is bound to be controversial - the project left
>> sourceforge some time ago due to dissatisfaction with the quality of
>> its facilities. I would have thought there would be room within the
>> existing mplayerhq infrastructure for this.
> I don't have any particular connection to mplayerhq. I would rather try
> to use some separate facility. I don't know what the problem was with
> sourceforge. 

Given that the ffmpeg project doesn't seem to be interested in releases,
I can understand the desire to be independent of the ffmpeg
infrastructure. However, sourceforge has had serious stability and speed
issues in the past (two complete cvs outages of several days duration
this spring, for instance).

So far as I'm aware it offers some CVS support and a forum
> of some kind along with support for download of tarballs. That would
> seem to suffice for now. What I'm thinking for a baseline is to take the
> last SVN version that passed its regression tests and call that a
> release candidate then go through the testing and see if it seems
> adequate at a black-box level: compare test coverage to executables and
> their command-line options/parameters. 

Using code coverage is probably a very good idea. In addition, there are
lots of projects that link to libav*, so tests that cover the apis of
the libraries would be great too.

> One thing which can be done is to
> use the Perl test facilities to control the testing. There is no
> particular requirement that a Test::More case be pure perl. Anyway, once
> that version passes muster it becomes v1.0 and we then look to see what
> newer stuff can be incorporated. The code which broke regression tests
> is inherently unacceptable for inclusion in release until valid test
> cases for it are built by the developer.

Sounds good, and I'll probably be contributing to this project with test
cases if it gets off the ground.

Regards,

  Uli