[FFmpeg-devel] Getting the FFmpeg 0.6 ball rolling

[Michael Niedermayer]

On Wed, Feb 03, 2010 at 10:02:29AM +0100, Robert Swain wrote:
> Hello good peoples,
>
> We made the 0.5 release on the 3rd of March last year. It's now the 3rd of 
> February. Maybe it's time we get the ball rolling for another release so 
> that distributions can resync to a newer version.
>
> First off, it seems that at least from Debian/Ubuntu's perspective, the 
> release was appreciated. Thanks to Diego and others that helped to get the 
> 0.5 release out the door.
>
> Diego took a hard line last time that we would do the release on his terms 
> so that we could at least get one out the door without getting bogged down 
> in endless discussion and flaming. And then we could review its success 
> afterwards.

it was a failure :)


>
> The last release was supposed to receive only backporting of security fixes 
> and no bug fixes. We originally intended to have a second release after 
> about 6 months but this didn't happen.
>
> It is suggested that policy for this release be outlined at the beginning. 
> I think we should maybe limit the discussion to a couple of weeks at most 
> after which we hit release process hard. I don't think we should talk 
> endlessly to create the 'perfect' release, but rather act on a few 
> pertinent issues and try it again to see how it goes and what works best.
>
> Initial proposals for the next release:
>
[...]

> I know the two-week-freeze on trunk was a cause for concern last year but 
> it seems to be the most effective way to make a release.

1. "We should try X this time we will later evaluate it, no discussions now"
2. "We did X and it worked so we will do it again its the best way because i
    say it is so wo wont try and evaluate an alernative"
3. "We always did X and everyone does X so its best"

I was against a freeze last time, and iam against a freeze this time.
Last time the argument of "try it once" was used to silence all logic,
we did try it once. Now its time to try alternatives


> It should focus 
> everyone's attention on fixing bugs for just two weeks. That benefits trunk 
> as well as people wanting to make a release.

quickly fixing bugs is the best way at introducing new bugs, the new ones
might be easy to fix but you wont even know they are there for bugs
fixed in the last few days. And as we never accept bug reports againt
non head we can easyl brush that under the carpet


>
> Otherwise, I think 0.5 went pretty well and didn't cause too much 
> inconvenience or extra work load on out part.

above all it caused little inconvenience for the cracker scene as they
didnt have to adapt their exploits

anyway, my comments are the following
1. If someone wants to make a release, all fine i wont stop him
2. If someone wants a freeze he can fork and freeze his fork
3. I insist on the maintainer having the knowledge to be able
   to recognize security fixes on svnlog and backport them as well
   as the time and will to do it for at least twice the time we
   expect until the next release.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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/20100203/128a6c6c/attachment.pgp>