[FFmpeg-devel] [RFC] Releases

Mon May 31 17:41:06 CEST 2010

On Mon, May 31, 2010 at 04:17:35PM +0200, Reinhard Tartler wrote:
> 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.  

Then you misunderstand what i meant with distros.I consider distro users
surely as our users. With distros i only meant the package maintainers and
people in charge of distros, not their users.

> No distro
> *wants* slow pace; 

I disagree, debians very rare stable releases may be argued to be unavoidable
but their choice of not updating packages except for security reasons in
stable between is a concious choice aka "want".

> 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]:
[...]
> 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.

i disagree with your view.
libav* should like any other lib ensure compatibility of its ABI/API
unless the major version /soname is bumped
and applications should only use the public API/ABI
if libav* breaks its ABI, we messed up and we should be beaten with a stick
if an application uses non public ABI that application should be fixed
upstream.
distros should use the latest releases that are considered stable by
the respective upstream.

IMO the idea of debian stable that refuses to update its software is not
fit for todays quickly advancing world nor was it in the past.
And i have no interrest at all to support it because it actively harms
users, by giveing them outdated, exploitable and buggy software.
(yes you do outstanding work with 0.5 and 0.6 but thats just now and you,
 before
 this there where known exploits for a very long time and there are many
 packages in debian where security issues that could be fixed with a
 single line chnage lay years with no action.)
And iam speaking as someone who used debian since more than 10 years on
various computers. Dont ask me on how many of my computers the debian
"stable" kernel worked thelast time i tried. Dont ask me how many
packages ive run into in stable that simply dont work at all.
And yes i should have reported it all but almost every problem i had
disappeared by upgrading to upstream
And one of the few i reported led to the package being removed instead
of the single line change that would have fixed it.

IMO what actually exists is not thousands of packages that work fine but
are somewhat outdated. What exist are hundreads of packages that have
been patched to compile without ever being tested or working at all.
so yeah you have 61 packages to compile with ffmpeg 0.5 but how many
are actually doing what the user wants in actual day use?
I claim the users would be better out with ffmpeg 0.6 and maybe 3 of
these packages less. Projects that use internal ABI so that they
continously break likely mess up in many other ways too and its
something that should be brought up on the upstream MLs and fixed
there

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100531/80b2f114/attachment.pgp>