ffmpeg in devel: to bump or not to bump

[Thorsten Leemhuis]

On 14.09.2008 14:19, Hans de Goede wrote:
> Dominik 'Rathann' Mierzejewski wrote:
>> Apparently I haven't been communicating my intentions widely enough, so
>> I'll try starting a thread here for a change. ;)
>>
>> Anyway, I'm sorry to bother packagers of ffmpeg-dependent software,
>> but I'd like to upgrade to a post-20080908 snapshot in a few weeks.
>> ffmpeg SVN r15262 introduced a bump to major libavcodec version, so
>> all dependent packages will need a rebuild. The last time this has
>> happened was in r4726, over 2 and a half years ago. There are some
>> API changes going on right now so I'm not going to do it just yet.
>> This is only the first heads-up.
>>
>> If you think I shouldn't do that, speak up now. ;)
> 
> I think it would be good to atleast make the jump in development, assuming the 
> APi changes are minor and either don't impact using software at all or can 
> easily be fixed. Then once we've done this in development (which we need todo 
> some time before F-10 launch to allow for testing, iow now) we can evalutate 
> this and maybe do the same for F-9 and F-8.

In the recent Livna past we failed once badly when we tried to upgrade 
to a new faad2 and ffmpeg in a stable release. I really want to avoid 
that we run into similar problems again in RPM Fusion, thus we IMHO 
should only consider updating to a new ffmpeg in a stable release if we 
know that things work for us and the users. That from my point of view 
mainly means:

- prepare all the API adjustments (if needed) to the packages that 
depend on ffmpeg
- test-build all the packages with the new ffmpeg on the release in 
question; after that at least roughly run-test the most important 
(xine-lib-extras-nonfree, vlc, mplayer) of the newly compiled apps 
together with the new ffmpeg
- if everything works out commit and build the new ffmpeg; immediately 
after it finished commit and build all the needed updates or rebuilds 
for other packages that depend on ffmpeg; then push them into testing in 
one batch (this point really is important to me)
- give it a bit more testing time then usually; if everything works move 
package over to stable

Cu
knurd