[Ffmpeg-devel] Creating releases
Sat Apr 14 14:31:31 CEST 2007
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
>> 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
> test compilation and regression tests on several different
> 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:
- 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.
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.
More information about the ffmpeg-devel