[FFmpeg-devel] [RFC] Releases

[Michael Niedermayer]

On Mon, May 31, 2010 at 07:42:02PM +0200, Reinhard Tartler wrote:
> On Mo, Mai 31, 2010 at 17:41:06 (CEST), Michael Niedermayer wrote:
> 
> > 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:
[...]
> 
> > 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.
> 
> which doesn't work in practice, because
> 
> > IMO the idea of debian stable that refuses to update its software
> 
> And your idea that this...
> 
> > is not fit for todays quickly advancing world nor was it in the past.
> 
> This does not match the opinion of the folks that actually run and use
> Debian releases. If you want something faster paced, there are a lot of
> other, less successful distros that actually do implement what you
> propose.
> 
> But is this a valid reason to penalize distros that do not share your
> view? I think not. It's a different philosophy how to run a distro. And
> that's OK in my POV.
> 
> > And i have no interrest at all to support it because it actively harms
> > users, by giveing them outdated, exploitable and buggy software.
> 
> Free software is about choice. Most users that choose debian do so
> because they do agree on how debian does releases. Otherwise they would
> choose a distro that suits them more, no?

no ;)
i choose debian very long time ago not because they do what they do but
because it was the only free distro at that time, all others had one or
both feet in the capitalistic/commercial world

but as you raise this, did debian ever ask their users if they want
all the packages that badly outdated?


[...]
> > 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.
> 
> I'm sorry about your frustration with your experience with Debian. I
> don't claim debian's approach to releases to be perfect, but for my
> personal and work-job uses which includes both desktops and servers, it
> works great. And according to distrowatch.com and similar sites, I'm not
> alone with that opinion.
> 
> This doesn't mean that we cannot do better. The last thing you've said
> in your mail leads me to an proposal:
> 
> > 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
> 
> in a perfect world without deadlines, disagreements and all flames, this
> would work.  Since I do not live in utopia land, we could do something
> that should almost match your idea:
> 

> Let's do the fast paced releases strictly time based. 

we should skip a release if fate is not green


> Based on that,
> I'll provide packaging so that FFmpeg can provide always uptodate Debian
> packages that replace the system FFmpeg. (Actually, that's already on my
> todolist, but anyways). These packages get uploaded to Debian
> experimental ASAP, and for ubuntu to a PPA.

this is a step in the right direction

also we maybe could extend fate to test interaction of ffmpeg&libav* with
various applications.
linking & compilation for example should be relatively easy to test
and iam sure some projects like mplayer would be happy if we did include
them on fate

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

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/71ed1afe/attachment.pgp>