[Ffmpeg-devel] Creating releases

[Robert Swain]

Hey,

On 14 Apr 2007, at 13:00, Michael Niedermayer wrote:
> On Sat, Apr 14, 2007 at 01:51:39PM +0200, Luca Barbato wrote:
>> Axel Thimm wrote:
>>> What do you think?
>>
>> Are you planning to branch from svn every N days, take M days
>> selectively adding just bugfixes and then make it the master  
>> snapshot?
>> Or are you just planning to just take a snapshot at a defined day and
>> make it the common ground for every distro interested?
>> Or you plan to make a new release every time the internal version
>> numbers changes?
>
> also are you planning to extensively test the release against the mphq
> samples archive and compare the against the previous release to detect
> regressions?
> test compilation and regression tests on several different  
> architectures?
> test make install?

Mike Melanson's build test setup might be useful for something like  
this. ( http://builds.multimedia.cx/ are the beginning stages of  
it. ) He tests on multiple architectures and plans to modularise each  
stage (configuration, compilation, installation) and the regression  
tests, etc. and tabulate the results, if I recall correctly.

> write uptodate README/INSTALL files?
> update the changelog?
> ...

Releases require at least a little coordination between developers,  
documenters and whoever wishes to administrate the release. There's  
nothing stopping development continuing at its own pace as it does at  
the moment, alongside a group of people who work on releases. Maybe  
there are some developers who would be interested in trying to keep a  
release schedule going with some organisation of features to be  
added, bugs to be fixed, documentation to be improved between  
releases and so on.

Just some ideas I'm pulling out of my head that may be worthy of  
discussion and are sort of related:
- Website
   - News entries need to be more regular
   - From an aesthetic point of view the site could do with an  
overhaul in my opinion
   - From a functional point of view could we/do we have some public  
bug tracking system?
   - Personally I quite like the tickets with milestones etc  
organisation approach and I'm aware there are many systems with these  
features and with associated wikis and similar.
- Volunteers

Bearing in mind that many people don't like working to schedules (me  
included most of the time, unless it's a long term schedule) I'm  
inclined to suggest that if a group of people are willing and able to  
discuss what goals they wish to achieve for a particular release, and  
are happy to carry out the work to achieve those goals, later  
coordinating with the rest of the developers to see if anything else  
should be pulled in to the release, that this could be a productive  
but flexible approach.

Any comments?
Rob