Re: ffmpeg in devel: to bump or not to bump
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