[FFmpeg-devel] Getting the FFmpeg 0.6 ball rolling

[Felipe Contreras]

On Wed, Feb 3, 2010 at 11:02 AM, Robert Swain <robert.swain at gmail.com> wrote:
> - Encourage downstream to report bugs against the release and submit patches
> back to us. At least then we can verify if they are still bugs in trunk, if
> not then we can backport the fixes, if so we can review their patches and
> merge them or fix them in a better way as we choose.
>
> - Make point releases (e.g. 0.6.1) when enough patches have
> accumulated/significant patches land/enough time has passed without more
> patches coming in.
>
> Maybe if we tried the above, we could get better ties with downstream in
> terms of releases.

Definitely. What "downstream" wants is stable FFmpeg releases (e.g.
0.6.1) but for that you need to have a "stable" branch so patches are
backported from the main branch, while development continues
unaffected. Otherwise we are forced to bump to random revision points
in order to get the good stuff.

Also, if you want to involve downstream, it's nice to mark release
candidates so that people can start massive testing in order to find
obvious issues. rc tags makes the conversation clearer: known issue of
rc1, fixed on rc2.

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

While I think it's desirable to concentrate on bugfixes before making
a release, the people that want to continue development should be able
to do so. That's what branches are for.

Cheers.

-- 
Felipe Contreras