[Ffmpeg-devel] Re: Advocating periodic releases

[Dana Hudes]

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.


>
> Tim
>