[FFmpeg-devel] release feedback

[Diego Biurrun]

So the release is done, time to think what went good and bad about it.

In the outside world the feedback was overwhelmingly positive.
Everybody seemed to be delighted to see an FFmpeg release.  Some
people even saw fit to express their gratitude in private.  Your
kind words are very much appreciated.

The target audience for this release were distributions and projects or
companies reusing FFmpeg.  From what I have heard they received exactly
what they wanted.

As for the release process, it could surely be improved.  It was bad
luck that roundup broke at the time we wanted to have the bug fixing
weekend.  I had hoped that more people would be motivated to work on
fixing bugs during this weekend.  Some actually did, but the interest
was not overwhelming.

The freeze took longer than planned due to the issues mentioned above.
The next time around, I would not extend it, but just the two originally
designated weeks should not slow down development in any way.  AFAICT
what was stopped during the freeze was just merging, not development.

One question that remains is whether we should repeat this regularly or
at all.  Given the positive feedback, I believe we should institute a
regular release schedule.  I envision time-based releases every 3 or 6
months.  After some thought, 6 months sounds preferable.  It is less
disruptive to the development process and a schedule that seem to work
well in a lot of other FOSS projects.

Feature-based releases seem to be constantly hampered by feature creep.
There will always be a feature or bug fix that just has to go in and the
release date can thus get pushed back continuously.  This is partly due
to the fact that the next release will be a long and unforeseeable time
in the future.

Time-based releases with a regular and dependable schedule solve this
problem.  I believe it is the way to move forward.

The other question is ongoing support for releases.

I think we should just port security fixes to the release branch.

IMO continues updates to the release branch are a workaround for a
release that is too long and/or too unpredictable.  The correct solution
is to find a rhythm that suits everybody.

Otherwise precious manpower that could be put to better use improving
the trunk is bound by release work and - IMHO - wasted.

There is one issue for which I would make an exception right now:
LGPL libswscale.

Making libswscale compile as LGPL would make it usable for a broader
audience of projects / users that cannot use it as GPL.  Furthermore,
the README in the release is already ambiguous about the issue and
it just requires adjusting one or two #ifdefs, so there cannot really
be any regressions.


That's more or less all I have to say, so now I'd like to hear your
feedback.

Diego