[Ffmpeg-devel] Re: Advocating periodic releases
Fri Oct 6 08:53:46 CEST 2006
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. 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. 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.
More information about the ffmpeg-devel