[FFmpeg-devel] release feedback

[Alex Converse]

On Sat, Mar 14, 2009 at 3:06 PM, Diego Biurrun <diego at biurrun.de> wrote:
> 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.
>

I fixed a bunch of bugs before the bug weekend with the hope to work
collaboratively on the harder bugs.

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

I think the freeze in the future should be harder and shorter. During
the freeze only crash fixes regression fixes and documentation fixes
should go in. But the freeze should only last two day or so. Possibly
only long enough to see FATE painted green.

Documentation should be kept up to date with current development.
There shouldn't need to be a big docucrunch before a release.

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

There were crash fixes (with possible security implications) before
the release that weren't back ported. The release branch is also not
visible on the git mirror leaving it out of sight/out of mind.

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

Now that libswscale is on by default I really think we should move it
to the main repository.

>
> That's more or less all I have to say, so now I'd like to hear your
> feedback.
>
> Diego
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>