[FFmpeg-devel] [RFC] Releases

[Jean-Daniel Dupas]

Le 31 mai 2010 ? 20:25, Michael Niedermayer a ?crit :

> 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
> 

Just a question, as you're talking about test and regression.
During the last months, changes in H.264 broke the multi-threaded decoder a couple of times.
I know nothing about fate, but is it possible to include some tests that uses multi-threading to prevent that kind of regression ? 


-- Jean-Daniel