[FFmpeg-devel] [RFC] Releases

[Reinhard Tartler]

On Mo, Mai 31, 2010 at 04:48:06 (CEST), Michael Niedermayer wrote:

> On Mon, May 31, 2010 at 12:12:50AM +0200, Diego Biurrun wrote:
>> On Sun, May 30, 2010 at 11:15:41PM +0200, Michael Niedermayer wrote:
>> > 
>> > I think we should do releases more often than we did historically or
>> > not at all. Otherwise everyone will use very outdated ffmpeg&libav*
>> 
>> I can understand that you want to see people use the latest and greatest,
>> but for some strange reason people just have their own priorities that
>> are at odds with yours/ours.
>
> both users and developers alike want the latest and greatest, its distros
> who partially want a slow pace. Which is understandable but not in our
> nor our users interrest.

In the way as you write it here, this is wrong and in some ways (not
necessarily as you write it here but in other mails) blunt, because your
sentence implies that distro users would not be 'our' users.  No distro
*wants* slow pace; their job is to *integrate* software packages in a
way that they fit together.  Since you seem to like picking on Debian,
let me list the *61* packages (with versions) that link against Debian's
system FFmpeg, which is taken from the ffmpeg-0.5 branch [I've listed
source packages that build-depend on libavcodec-dev, this might be
slightly inaccurate]:

alsa-plugins: 1.0.22-1
amide: 0.9.2-1
audacious-plugins: 2.3-2
audacity: 1.3.12-3
avbin: 7-1
cherokee: 0.5.6-5
dvswitch: 0.8.3.1-1
ffmpeg-php: 0.6.0-2
ffmpeg2theora: 0.24-2
ffmpegthumbnailer: 2.0.2-1
ffprobe: 0.svn92-1
freej: 0.10git20100110-1
gdcm: 2.0.14-9
gimp-gap: 2.6.0+dfsg-1
gmic: 1.3.5.0+dfsg-1
gnash: 0.8.7-2
gnusound: 0.7.5-3
gstreamer0.10-ffmpeg: 0.10.10-1
guvcview: 1.3.1-1
idjc: 0.8.2-2
igstk: 4.2.0-3
imageshack-uploader: 2.2+hg20100408.d802dea89428-1
iulib: 0.3-1
kdenlive: 0.7.7.1-2
kino: 1.3.4-1
ktoon: 0.8.1-4.1
kwwidgets: 1.0.0~cvs20090825-4
libavg: 0.8.0-6
libphash: 0.9.0-2
libquicktime: 2:1.1.5-1
libvalhalla: 1.0.1-2
linphone: 3.3.0-1
lynkeos.app: 1.2-4
moc: 1:2.5.0~alpha4+svn20091009-1
moon: 1.0.1-3
motion: 3.2.11.1-1
mpd: 0.15.9-2
mplayer: 2:1.0~rc3+svn20100502-3
mt-daapd: 0.9~r1696.dfsg-15
netgen: 4.4-15
opal: 3.6.6~dfsg-3
opencv: 2.0.0-4
openmovieeditor: 0.0.20080102-2.3
paraview: 3.4.0-5
performous: 0.5.1-1
picard: 0.11-2.1
potamus: 0.10-1
pyofa: 1.0.3+hg20090101-1
qmmp: 0.3.3-1
qutecom: 2.2~rc3.hg396~dfsg1-6
renpy: 6.10.2.dfsg1-1
smilutils: 0.3.2+cvs20070731-4.2
sox: 14.3.1-1
synfig: 0.62.00-2
taoframework: 2.1.svn20090801-2
unicap: 0.9.5-1
vlc: 1.0.6-1
vtk: 5.4.2-6
xine-lib: 1.1.18.1-1
xmms2: 0.7DrNo-5
zoneminder: 1.24.2-3

I expect that there will be a few more packages in addition in ubuntu.
Anyway, in order to get a debian stable release out, *all* of these
packges need to agree on a single version of ffmpeg, and that's the
purpose of the system ffmpeg package.

And no, from a security POV static linking or embedding ffmpeg in all
(or most of thesse packages) is not an option.

>> [...]
>> 
>> Now I'm very happy that I managed to recruit Reinhard to help with
>> releases, but our two person release team is still understaffed.
>> On top of that 0.6 is considerably more work than 0.5 was.
>
> Id like to hear reinhards oppinon on this thread

Thanks for your interest.

Because of the vast amount of packages that distro maintainers like me
have to consider here, I have to set a synchronization point for the
version of FFmpeg all packages have to work with against. For the next
version of Debian, this will be FFmpeg 0.5, and currently I know that
all of the packages above work with that. Having significantly more
potential synchronization points will just lead to upstreams requiring a
newer version of FFmpeg that has high potential to break other otherwise
unrelated packages.


>> I don't have enough time to make even 3-monthly releases...
>
> Understood
>
> Reinhard, do you have the time for this or should i try to find someone
> else? I probably could do it myself but you did it pretty well and i dont
> think, given my disinterrest in releases, that i would achive the same
> quality.

In principle, I think I could also do faster releases. But let me
express my understanding of the requirements.  OTOH, we have developers,
that want to develop and experiment always with the latest and greatest.
In order to get "the crack of the day", svn and compiling statically is
obviously the and most convenient method here. Every FFmpeg developer
fits in this class. For this group, daily releases (== "svn checkouts"?)
are probably the best choice.

Then there is the group of developer that works on application packages
(think mplayer, xine, vlc, etc.).  They would probably benefit from
faster releases than we currently have, maybe 3-6 monthly releases I'd
guess.

The last group are system integrators and distributors that need to get
a large amount of packages working together. These are almost always
very busy at very boring tasks like figuring out in what weird and
broken ways application packages misuse ffmpeg's APIs and try to fix
them. For them I'd guess 12-18 months releases would suit best.


As compromise I could therefore indeed imagine to do 3 monthly releases,
but *in addition* declare some of those releases as special, long-term
releases that are targeted for distros and system integrators.  These
would then probably come with a more elaborated changelog and APIChanges
diff, and probably other things that simplifies the work of system
integrators.

And yes, if there is some interest in having 3-6 monthly releases, I
would be volunteering to run such releases, but obviously with less
effort than I've put in this 0.6 release.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4