[FFmpeg-devel] FFmpeg 0.6 status update

[Michael Niedermayer]

On Sat, Mar 13, 2010 at 05:24:28PM +0100, Reinhard Tartler wrote:
> On Tue, Mar 02, 2010 at 15:09:12 (CET), Reinhard Tartler wrote:
> 
> > Currently, we plan to try Mar 13 as date X, but depending on the
> > resulting discussion about this announcement, we can also delay it a few
> > days/weeks. Depending on the condition of the 0.6 branch on day X + 7
> > (this might be Mar 20), we can ideally release in the week between 22-27
> > of Mar.
> 
> Okay, that would be then today. looking at FATE [1], things seems to be
> mostly fine, with some known test failures. The single known build
> failure is on ia64 and caused by a gcc bug (according to mans, our .bss
> segment is about 5MB, but gcc fails to handle that, so *shrug*).
> 
> Regarding the other FATE test suite failures, does anyone care to get
> them fixed for 0.6? And more importantly, does anyone have good reasons
> or pending patches to delay creating the branch for one week? In any
> case, we will still accept/backport selected changes for another week,
> but we need to know if trunk is currently a good basis for a new
> release.

there will be more error concealment bugfixes from me in the next days

anyway it doesnt really matter when 0.6 is branched, it will be outdated,
obsolete and more buggy than trunk a month later. What point does this
excercise have? For actual use trunk will be better than 0.6.
for the sake of outdatedness we have older releases.
lower buggyness is not achived with a fork once a year because such
forks have no users after a month that are capable to report bugs.
You just have users that dont use it much and users who dont know
how to upgrade. You can guess the reasons why neither of these groups
can provide good bugreports.
And there are no developers who know the code and would review any patches
So after a month you just accumulate patches that break more than they fix.
Of course one can pretend its otherwise but iam using debian on many systems
and know too well that many packages are so bug-patched that theres no
way they can be used anymore.
and security wise, a moving target is harder for an attacker than a
year long not changing one.

my oppinon is debian should package ffmpeg trunk, and only that.
If there are problems with this like ABI changing these should be
discussed with us so it can be fixed in trunk

packaging yet another, "soon to be outdated" version that is not
supported by us is not a good idea.


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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20100313/9c165f76/attachment.pgp>