[FFmpeg-devel] Getting the FFmpeg 0.6 ball rolling

[Robert Swain]

On 03/02/10 14:33, Michael Niedermayer wrote:
>> 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

I did think of the branch + freeze branch aside from release 
manager-OKed bug fixes approach. We can try that if that is what is desired.

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

Maybe we don't accept bug reports against non-head now, but maybe 
someone stepping up to be a release maintainer would be happy to receive 
bug reports against the release version and verify against head to 
backport fixes or issue a bug report upstream to us on roundup.

I think you have a point about quickly fixing bugs though.

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

As mentioned, this may well be deemed reasonable.

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

Sounds good.

Regards,
Rob