[Ffmpeg-devel] Re: Advocating periodic releases

[Dana Hudes]

Ulrich von Zadow wrote:
> 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
>   
OK, there seems arguments against using sourceforge. Putting that aside, 
we need defect and other issue tracking. E-mail is fine but  not 
terribly organized. This is fine for putting up proposed patches and 
then discussing them but I'm envisioning a quieter sort of situation and 
a means of keeping track of what's broken, fixed, etc. .  I have 
experience using Mantis (an older version mind you, I'm working to put 
up the new version on a new installation of the OS -- solaris 10 vs. 8 
-- along with php and mysql). It does what we need EXCEPT that in the 
old version we currently run at work you can't see a list of all issues 
unless you have developer privileges. I'm going to bring up the new 
version in the next few days but this may be a design approach of mantis 
which compares unfavorably, IMHO, with bugzilla. What Mantis DOES have 
nicely is multiple projects, which can be public (you still have to be a 
user of the system, there's no provision for details of a ticket to be 
readonly visible) or private (i.e. by invitation only, the manager of 
the project has to add the user to the project in order for them to 
participate). That would allow separate projects for e.g. the release 
itself and for test case development. I'll get back to this after I get 
the new Mantis up at work.
(did I mention I'm a Sun Solaris  UNIX admin for a living?)